On Sun, 18 Mar 2007, Tom 'spot' Callaway wrote:
It seems like everyone keeps asking me in private to speak on the
topic
of using a repotag for EPEL, probably since I'm the one who decided to
not use one for Fedora Extras (the decision predates the Fedora
Packaging Committee).
The first problem I have with overloading Release with a repotag is that
we start to play games between repositories:
foo-1.0.0-1.el5.epel < foo-1.0.0-1.el5.notepel
Is it really? Nah. This is just RPM trying to make sense of what we've
shoved in there.
If that really is a concern, then you loose anyway by not having one.
foo-1.0.0-1.el5 < foo-1.0.0-1.el5.rf
Besides this case is only useful when releases are identical, which often
they aren't and there is no reason to assume that:
foo-1.0.0-4.el5 > foo-1.0.0-2.el5.rf
either. So whatever the point is, a repotag simply does not affect the
version comparison in an important way, because releases from different
repositories simply cannot be compared. Any attempt doing that is
brain surgery. Higher does not mean better, besides RPMforge looses anyway
because most packages have a release of 1, while EPEL seldom has 1.
Moot artificial point.
Is this better than having two repositories with the same n-v-r? I
don't
think so. We're not really solving this problem by using the repotag.
There is nothing to solve. A repotag does not help or break release
comparison. Nothing to compare here, please move along.
We're now in the realm of "my repotag is considered larger
than yours by
RPM". We might as well be playing games with epoch. Is this the intent?
Almost certainly not, but it is the side-effect.
Moot point. It must be paranoia talking if you think the only reason for a
repotag is to influence the version comparison. First mention ever.
(actually michael deserves that credit !)
The second problem is determining where a package came from. This
seems
like a legitimate problem, but I'm not convinced that using a repotag is
the best solution. To me, this seems like a better use for the Vendor
tag. Now, if we use the Vendor tag, the problem becomes that users don't
see the Vendor tag when they query the package to file a bug.
So you want to restrict Vendor tags to something short ? What will then
hold the former Vendor information ?
The %{_query_all_fmt} tag controls the output that users see when
they
query installed package(s). Perhaps EPEL users (with epel-release
package installed) get a%{_query_all_fmt} redefined to
%{name}-%{version}-%{release}.%{vendor} (or something like that). Then,
the origination repository is clear on an rpm query, so we solve this
problem, without overloading Release.
Right. Let's see how that looks on a production system:
[dag@host ~]$ rpm -qa --qf '%{name}-%{version}-%{release}.%{vendor}.%{arch}\n'
apt-0.5.15lorg3.1-4.el3.rf.Dag Apt Repository,
http://dag.wieers.com/apt/.i386
basesystem-8.0-2.Red Hat, Inc..noarch
bash-2.05b-41.5.Red Hat, Inc..i386
InterDo-3.5.6-17.KaVaDo Inc. <
http://www.kavado.com/>.i386
ISSXss-6-6.5.1.(none).i386
j2re-1.4.2_03-fcs.Sun Microsystems.i586
TIVsm-API-5.2.4-0.IBM.i386
TIVsm-BA-5.2.4-0.IBM.i386
(It amases me how proactive IBM at times can be)
Now, will that affect Yum, Apt and other tools as well ? Do they use
%{_query_all_fmt} ?
Besides this breaks a lot of scripts that do not expect spaces (or
dashes) in rpm -qa output and it becomes impossible to extract information
from the filename like was possible in the past. name="${file%-*-*}"
I always prefer to discuss problems and possible ways to solve them
(and
then try to find the least intrusive way). :)
Thanks Tom !
PS If I sound bitter, it's just because after 5 years and having this
discussion for 4 times we return to proposals like this one.
Kind regards,
-- dag wieers, dag(a)wieers.com,
http://dag.wieers.com/ --
[all I want is a warm bed and a kind word and unlimited power]