Relationship to existing 3rd party repos/CentOS/SL?

[Axel Thimm]

On Wed, Apr 25, 2007 at 04:07:12PM -0700, Fernando Lopez-Lezcano wrote:
> On Thu, 2007-04-26 at 00:13 +0200, Axel Thimm wrote:
> > On Wed, Apr 25, 2007 at 02:51:50PM -0700, Fernando Lopez-Lezcano wrote:
> > > So, am I making things worse if I decide to keep repotags?
> > 
> > Only to yourself, you aren't harming anyone else by keeping them.
> > 
> > > (because then I don't contribute so strongly to the predictable
> > > confusion that some hope will highlight how repotags can be useful
> > > for no additional cost?[*]). Sounds really really silly to me.
> > 
> > The point is that this system only works if all (major) players
> > cooperate. Once one decides to not play nice anymore this system is
> > broken and starts damaging the ones that support it. At the end you
> > will be the last remaining martyr. :/
> 
> My (potential) packages will be easily identifiable with just an rpm -q.
> How is that bad? (for Planet CCRMA). Why is it best to hide if others
> hide? 

I already outlined, that once a 3rd party repo break this common rule,
it automagically becomes the standard base for novice users pushing
all issues to the other repos. Here is a typical report I get since
freshrpms dropped repotags:

 "migration to at packages from fc causes (minor) grief"

 "[... rant ...] was wondering why it is that you do what you do, specificially,
  replacing FC packages with your own [... rant ...]
  libquicktime-0.9.10-2.fc6.i386"

This is an easy case where I know the packages cannot be from the
vendor, since they are banned there. But the users have no idea and
their first impulse when foo-1.2.3-4.ccrma and bar-1.2.3-4 break is
that it can't be the non-adorned version's fault, since everyone knows
that that's the official one.

So the repos that drop repotag shift the support issues to the ones
that continue carrying it. That's an unfair and unbalanced situation
and there is just not enough manpower to waste, so everyone gets
forced to drop repotags to restore the balance.

You can rightfully argue that if rpmforge, ATrpms and co drop the
repotag now, too, they just add to the problem, and that's true for
the remaining repos that want to carry one like you want to, but there
aren't many degrees of freedom left unless one likes to get more
support issues than really neccessary. The second, third, forth and so
on repo that will drop the repotags are not to blame, the first one
introduced the situation.

> > That's why I went through endless lengths to have epel carry repotags,
> > so we could live all together in the same ecosphere.
> 
> Yeah. Predictable result.

Not at all: At the beginning it looked like epel wouldn't mind
repotags, there was only one opponent that finally left this list. And
sibling entities like the FPC tended to back up any epel plans to
introduce them. When epel finally came close to get some, another
opponent woke up and made a lot of noise and created the current
situation.

> I think it also took a long time for the RedHat/Fedora/Extras
> distros to realize it is good practice to add a _distro_ tag to all
> packages...

Indeed, currently 89% of fedora carry one with a per release increase
of >= 10% for the last three releases. So the extrapolation gives that
F8 will be covered 98% with disttags unless the disttags are swamped
in FUD which some people currently try to do. But that's another sad
story.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/epel-devel/attachments/20070426/576429ab/attachment.sig>