repotags (was Re: EPEL report 2007, week 19)

Dag Wieers dag at wieers.com
Sun May 20 14:00:19 UTC 2007


On Sun, 20 May 2007, Thorsten Leemhuis wrote:

> On 18.05.2007 20:02, Axel Thimm wrote:
> > On Fri, May 18, 2007 at 09:50:09AM -0700, Fernando Lopez-Lezcano wrote:
> > [...]
> > fpc had signaled that they would
> > pass any decision of epel to introduce repotags
> 
> Hmm, I got different signals from Spot, which leads the Fedora Packaging
> Committee.
> 
> See:
> 
> https://www.redhat.com/archives/fedora-devel-list/2007-April/msg01393.html
> 
> Quoting
> ----
> But I'd like to point out that I'm still fundamentally opposed to the
> repotag, as I've yet to hear what problem it solves, aside from the
> "other repos want it" problem.

Ok, this is silly. spot should have joined the discussion instead of 
iterating over the same arguments brought up on this list.

 1. repotags makes packages unique (cross-repositories)
    (yes, this means you have to believe in a world where there is more 
    than just EPEL, stop reading here if you don't believe in that)

 2. repotags do not affect the version comparison in a useful way
    (since there is no point in comparing release tags between 
    repositories anyway, there is no relation)

 3. repotags help identify packages in every output
    (you can talk about extra headers and changing RPM, we don't have that 
    today and unless Red Hat commits to backporting RPM support for 
    repotags we won't have that tomorrow either)

With a Fedora hat, I can understand that people think 'who cares, we never 
needed it in Fedora, so why do we need it in EPEL' ? But that is 
shortsighted.

Asking to do rpm -qpi or anything else just worsten the experience for 
users and is a waste of time for anyone trying to help out.

Sure, RPM could be changed to support it outside of the release-tag.

Sure, Yum is not the best tool to support mixing repositories because it 
does not allow easily to select specific packages from specific repos.

All that can be improved, but without the mindset that there is more than 
one repository, all these changes will never happen. And I personally 
blame Fedora's single repo mindset as the main reason why the current 
situation is bad. Before Yum existed (apt) and with Smart these issues 
did/do not exist especially because they were designed to select 'other' 
versions of a package.

The big problem with EPEL is that people that use Fedora mainly are in 
charge of making the rules, and spot's expression is right on that spot.
(Did spot ever use RPMforge or ATrpms on RHEL/CentOS from within Yum, Apt 
or Smart ?)

Since it is pretty clear that CentOS Extras and EPEL will be seperate 
projects packaging the same RPMs, I hope some people wake up and realise 
that the Fedora mindset does not belong in EPEL.

Kind regards,
--   dag wieers,  dag at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]




More information about the epel-devel-list mailing list