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

[Axel Thimm]

On Tue, Apr 24, 2007 at 01:04:49PM -0700, C.M. Connelly wrote:
> Speaking as an end-user/sysadmin, I'm not clear on why the repotag
> issue is as controversial as it appears to be.
> 
> From my perspective, RHEL (really mostly CentOS) is the base OS.
> On top of that, I expect to layer EPEL packages, very likely some
> packages from RPMForge, and packages from my own local repos (for
> special needs or for packages that just aren't (and maybe can't
> be) available from other sources).
> 
> Having read all the messages on the topic, I agree that the
> current EPEL steering committee is not out to take over the world
> or *intends* to imply that other repositories are less important,
> but I can definitely see how Axel and Dag can *feel* like that's
> where the committee is coming from, because that's how it feels to
> me.

It is more than a bad feeling. If one repo drops repotags the whole
repotag system is broken. So the continued lack of repotags forces the
other repos to follow along even though they are strong belivers of
repotags.

Someone from the committee said that since he doesn't require the
other repos to do anything with their repotags, why should the other
repos require him to do something. He didn't realize that choices of
EPEL affect other repos (and vice versa, of course).

So the external request on repotags was not just a signal to play nice
and lay down future politics, but in fact a request to not be
disruptive on current RHEL community standards.

> My understanding of the argument from the no-repotag side is that
> EPEL is going to avoid package overlap with RHEL (upstream), so
> they're not technically necessary.

Still they are, of will you know by first glance whether yum reporting
conflicts between foo-1.2.3-4.el5 and bar-5.6.7-8.el5 will be due to
one package or both coming from EPEL and RHEL? Similar issues as with
other 3rd parties will pop up. And now that the other repos are forced
to drop the repotags mid-term as well, there will also be confusion
between RHEL and any 3rd party repo. RHEL support will certainly be
fascinated by the outcome of events.

> But EPEL is still a supplementary repo, just as RPMForge, ATrpms,
> and my own repos will be.  EPEL may avoid package overlap with
> RHEL, but it's very likely (almost guaranteed) that we will see
> overlap between EPEL and other repos.  Adding the repotag seems
> like a fairly neutral, technically free, and politically nice
> option that will help people sort out potential conflicts.  Not
> having the repotag *implies* that EPEL is upstream, pisses off
> some very skilled and valuable possible contributors and
> collaborators [*], and makes life just a little bit harder for end
> users and system administrators trying to support those end users.

Thanks, you couldn't have summarized it better. But the key persons
against repotags were aware of this and still voted them down. Now
everyone can ask himself why that happened.

>    Claire
> 
> [*] Suppose that over time EPEL's users and maintainers decide
>     to add a secondary repo with newer packages.  Wouldn't it be
>     great to coordinate that repo with other folks maintaining
>     similar repos?  Maybe even get them to maintain those newer
>     packages within the EPEL structure?
> 
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
>   Claire Connelly                              cmc at math.hmc.edu 
>   Systems Administrator                          (909) 621-8754   
>   Department of Mathematics                 Harvey Mudd College
> *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
-- 
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://listman.redhat.com/archives/epel-devel-list/attachments/20070425/8d3b16a6/attachment.sig>