Packages duplicated between EL-5 sub-channels and EPEL
Toshio Kuratomi
a.badger at gmail.com
Fri Jan 15 05:06:08 UTC 2010
On Thu, Jan 14, 2010 at 09:21:11PM -0700, Stephen John Smoogen wrote:
> 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.
>
Yep. If the alternative is going to take us into the realm of not having
certain packages in EPEL because something it depends on is in a layered
product and not in the layered products themselves then that option is
doesn't make much sense for us.
-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/epel-devel-list/attachments/20100115/8ae6cec3/attachment.sig>
More information about the epel-devel-list
mailing list