SCIENTIFIC-LINUX-DEVEL Archives

November 2007

SCIENTIFIC-LINUX-DEVEL@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Axel Thimm <[log in to unmask]>
Reply To:
Date:
Tue, 6 Nov 2007 17:14:29 +0200
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (2919 bytes) , application/pgp-signature (194 bytes)
On Tue, Nov 06, 2007 at 06:46:04AM -0700, Stephen John Smoogen wrote:
> On 11/6/07, Axel Thimm <[log in to unmask]> wrote:
> > On Mon, Nov 05, 2007 at 08:47:54AM -0600, Troy Dawson wrote:
> > > That's a good idea as well.  Find out which repositories from CentOS people
> > > want in.
> > > The one thing I worry about with EPEL is that I have heard that they often
> > > are not compatible with the CentOS, dag, and atrpms repositories.  I
> > > haven't confirmed this, just heard it once or twice.
> >
> > There isn't much to confirm. Since EPEL doesn't want to be compatible
> > and the others won't take a one-sided burden of compatibilty there
> > will be no compatibility. If it works it will be by happenstance not
> > design.
> 
> Axel, I know you are sleep deprived from a newborn, but that is BS.
> EPEL has done a lot of stuff to try and stay API/ABI compatible with
> CentOS and make sure that certain things work out of the box. They
> have removed packages that were already in CentOS and tried different
> tags to make sure CentOS didnt get over-written.
> 
> What they didn't do was do %dist tags, mostly because they felt
> certain groups drew a line in the sand of do it or else and they like
> every other developer are stupid enough to cross over it. They are
> paying for that as they have to go deal with various problems, and my
> guess is that in a year or two they will review and say "hmmm" that
> would be a good idea to deal with something.

Long before the newborn entered my life (and made me happier and
certainly more resitant to BS by EPEL) [1] EPEL was placed before a
choice of working with 3rd parties or not on the example of repotags
(*not* disttags). There were explicit requests (not by me) whether
this is to be interpreted as EPEL-Darwinism which were positively
acknowldeged by EPEL steering `chairmen'.

Sorry, that's far beyond BS and FUD, it's the way EPEL works. And the
few "compatibility" hooks EPEL implanted to support CentOS' yum
infrastructure were done after the storm and after many RH people woke
up on where EPEL was being driven to, but also after three (!)
negative votings on whether EPEL will try to keep an open channel to
other 3rd party repos or not. It also forced other repos to drop the
repotag system as that system only works as long as *all* repos play
nice. And as soon as a repo decided to go wild the system was broken.

Anyway, this list is not for rehashing what has been said 1000 times
on epel-devel. If one ios interested in history he can dig up the epel
archives. The fact remains that there is no interest on either side
epel vs rest of the world to even discuss compatibility.

So the basic answer is still: Noone will care about broken
compatibilities between epel and the rest of the world.

[1] I also feel that this comment on me being overtaxed and the choice
    of BS'ing my opinion is not really proper. Have a different
    opinion by all means.
-- 
Axel.Thimm at ATrpms.net


ATOM RSS1 RSS2