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

Fernando Lopez-Lezcano nando at ccrma.Stanford.EDU
Thu Apr 26 18:48:05 UTC 2007


Axel: in the following I'm __not__ blaming _you_...

On Thu, 2007-04-26 at 09:58 +0200, Axel Thimm wrote:
> 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.

Educate users then? Make sure that web sites clearly state facts about
repotags? 

> 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, 

Yes, that is what actually happens. I don't think I need to argue about
it, sounds to me like fact. 

> 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.

I disagree. The second __is__ to blame. Definitely. Come on, if one is
off it does not matter, no repotag means users automatically know where
it is coming from (same as _having_ a repotag). Now, as for the
_second_, there's no excuse for doing that unless you actually believe
repotags should die. Non-repo-tagged Extras was actually the situation
we were living in before EPEL (ie: Fedora Extras), and it did not suck
AFAIK. Now it will suck for both epel and extras. That's progress?

I can see your reasoning for the third and so on and so forth - still it
sucks. For the _second_ there's no _technical_ reason that I can see. 

I'm perhaps too stuborn but I don't see why we need to follow the lead
and jump off the cliff. It will make matters worse for everyone. 

> > > 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.

Nice. All it takes is just _one_ strong individual to derail things?
(hmmm, where's the news? :-) Were there people within EPEL that
supported this? How many? If there's effectively a single vote veto then
it becomes impossible to do _anything_. There's always going to be a
voice against, no matter what you do. 

> > 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.

So, what would have happened if all third party distros had dropped the
distro tag?

I understand people being pissed off (I am right now), but the right
answer to repotags not being considered for epel is _not_ to drop them
but to _keep_ them. In the hope (as with distro tags) that eventually
the advantages will become obvious and they are adopted. Or not.
Dropping them is ensuring that can not happen. Not a good choice if you
indeed believe they are useful. 

Sorry, I'll shut up now... this is not going to go anywhere. 
-- Fernando





More information about the epel-devel-list mailing list