Re: Re: Mixing RPMforge and EPEL (Was: EPEL repo)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On Mon, 30 Jul 2007, Les Mikesell wrote:

> Axel Thimm wrote:
> > On Mon, Jul 30, 2007 at 04:58:19PM -0500, Les Mikesell wrote:
> > > Axel Thimm wrote:
> > >
> > > > > I don't know enough about repotags to understand why everyone needs
> > > > > them.  Can't any repotag be distinguished from no repotag?   Why is
> > > > > there any need for cooperation beyond not choosing the same tag or
> > > > > lack thereof?
> > > > All the repotags request was about is to idntify epel packages as such
> > > > with a simple tag in the file name, no more, no less. And that already
> > > > died with an awful sound.
> > > If everyone else has added unique repo tags, isn't the lack of a tag an
> > > equally unique identifier?  I'm missing the point of argument here.
> > 
> > So you want to reiterate the whole epel-devel repotag fiasco here
> > argument by argument? 
> 
> No, I want to understand the effect on an end user when only one repo refuses
> to add a unique tag.  I don't want to fight the war - I want to know which way
> to duck.

Red Hat does not add tags, so there are at least 2 parties that do not add 
tags. Red Hat and Fedora EPEL. So yes, that makes it harder for people to 
know if a package came with the OS or with EPEL.

>From a debugging dependency point of view this is equally disturbing.


> > The argument was that once a repo drops the
> > repotag and foo-1.2.3-4 conflicts with foo-2.0.0-1.blahrepo the
> > typical user assumes the former to belong to the distro proper and the
> > latter to be the one causing the conflict.
> 
> I don't get it. What does the potential to drop a tag have to do with a tag
> not existing in the first place?

EPEL and RPMforge have the same packages, but not the same set if 
subpackages and interdependencies. If there is no repotag, packages could 
depend on subpackages from another repository where it makes no sense. The 
clamav packages are an excellent example. Please read the EPEL mailinglist 
for this example.

As a result of this and other examples, EPEL's advice is not to mix 
repositories (which fits nicely in their agenda). So there is an important 
advantage for not having repotags, it favors their repository because in 
dependency problem output you see non-tagged packages and rf-tagged 
packages. Who do you think people are going to blame.

And this is not just fake drama, we have been there with Fedora Extras. 
This strategy pushed away most 3rd party repositories.

You may argue that that is a good thing. But Fedora is a different beast 
than RHEL. People may want stable packages, or current packages and a 
single repository (with the tools we have today) cannot provide this.

Besides, it punishes people who did not have an alternative back when 
Fedora Extras refused to do RHEL packages and only had RPMforge to fall 
back on.

At least that's my point of view.

--   dag wieers,  dag@xxxxxxxxxx,  http://dag.wieers.com/   --
[Any errors in spelling, tact or fact are transmission errors]
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos

[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux