Packages duplicated between EL-5 sub-channels and EPEL

Stephen John Smoogen smooge at gmail.com
Fri Jan 15 04:21:11 UTC 2010


On Thu, Jan 14, 2010 at 8:43 PM, Toshio Kuratomi <a.badger at gmail.com> wrote:
> On Thu, Jan 14, 2010 at 05:21:31PM -0700, Stephen John Smoogen wrote:
>>
>> ================
>> found this by first looking for conflicts in packages and then doing a
>> reverse walk with
>> for i in $( cat file-of-conflicts  ); do repoquery  --disablerepo="*"
>> --enablerepo=epel --qf='%{NAME}' --whatrequires $i; done
>>
> Wait a minute.... So the first list is conflicts with  with
> RHEL layered products.  We're saying, these packages are in our new
> definition of RHEL and thereforewe need to drop them.  I'm with you so far.
>
> But why the second list?  If the package is in RHEL, then we need to check
> the second list and see if they can build/work with the version in RHEL,
> right?  Not outright drop?

The packages are in channels that are layered onto RHEL and not
available to customers who have not bought those products. Only the
SRPMS are available. Thus building those packages would be impossible
for someone who is trying to build stuff on CentOS or in the build
system. So basically you have to pull them because you can't build
them IF you following the rule as written.

Personally I think the point is we have to rewrite the rule to
basically if its in
ftp://ftp.redhat.com/pub/redhat/linux/enterprise/*/os/ we dont'
replace/overwrite.. but otherwise caveat empor. Especially since one
of the things EPEL allows for RH is to have packages that they know
are packaged to standards, work with EL (at somepoint of time) that
they can then pull back into layered products.


-- 
Stephen J Smoogen.

Ah, but a man's reach should exceed his grasp. Or what's a heaven for?
-- Robert Browning




More information about the epel-devel-list mailing list