[CentOS] Re: Mixing RPMforge and EPEL (Was: EPEL repo)
Axel.Thimm at ATrpms.net
Mon Jul 30 13:24:32 UTC 2007
On Mon, Jul 30, 2007 at 07:51:45AM -0500, Les Mikesell wrote:
> Axel Thimm wrote:
> >Maybe the original draft will be picked up by other projects to
> >signal their mode of collaboration, let's see. It certainly was in
> >thge spirit of the existing 3rd party repos.
> Maybe you should cut them a little slack considering that they are not
> so experienced as the rest of you...
Experienced in what? Hidden agendas and politics? I'm not experienced
in that really. Please check the epel list where these topics were
discussed over *months* and often revealed their political background
instead of a "lack of experience".
> >Furthermore there have been many quotes in IRC and mail of various
> >current EPEL steering members that they "aim higher" than the existing
> >repos or see EPEL as the only repo long term and the like.
> As long as there are policies about what can be in a repo or who can put
> it there, there can never be just one repo. Everyone should understand
> that by now.
> >On the positive side one must say that Max Spevack was interested in a
> >collaboration between EPEL and the rest of the world, but he's not
> >forcing it onto the EPEL people.
> I've never quite understood why you don't just give the packages
> different names if they already exist in the disto-supported repo but
> there might be some reason to want your version instead (or besides).
First of all there is no distro supported repo in this context, we're
talking about 3rd party repos.
Next, what use would it be to give a different name? E.g. xemacs vs
xemacs-myrepo? The two packages would conflict so xemacs-myrepo has to
either Conflict: or Obsolete:/Provide: with the standard name, and the
end result is a worse setup than having the proper name since there
will be no way back to the unadorned name unless the xemacs package
starts obsoleting/providing the alternate name as well.
So there is no real improvement in obfuscating names. And I didn't
even mention dependent packages that would break with
perl-Bar-myrepo and libfoo-devel-myrepo instead of perl-Bar and
ATM we'll just live and let live, and there will not be any one-side
effort to rectify any compatibility issues EPEL created. It's their
mess, they'll have to clean it up.
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.centos.org/pipermail/centos/attachments/20070730/7349af6b/attachment.bin
More information about the CentOS