My thoughts on repotag

[Dag Wieers]

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 at 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 at wieers.com,  http://dag.wieers.com/   --
[all I want is a warm bed and a kind word and unlimited power]