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