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(a)math.hmc.edu
Systems Administrator (909) 621-8754
Department of Mathematics Harvey Mudd College
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
--
Axel.Thimm at
ATrpms.net