[users] Dropping the repotag

[Dag Wieers]

Hi,

Maybe the below discussion could help introduce the repotag in EPEL.

Please let me know when the repotag will be decided for EPEL, so I know 
when to unleash hell :)

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]

---------- Forwarded message ----------
From: Dag Wieers <dag at wieers.com>
To: Andreas Rogge <a.rogge at solvention.de>
Cc: RPMforge <users at lists.rpmforge.net>,
    Nicolas Thierry-Mieg <Nicolas.Thierry-Mieg at imag.fr>
Date: Sun, 18 Mar 2007 14:37:12 +0100 (CET)
Subject: Re: [users] Dropping the repotag

On Sun, 18 Mar 2007, Andreas Rogge wrote:

> On Sat, 17 Mar 2007, Dag Wieers wrote:
> > On Sat, 17 Mar 2007, Andreas Rogge wrote:
> >
> > > What if you could use for example "listrpms --vendor RPMForge" 
> > > instead of "rpm -qa | grep rf" and get a 100% result without 
> > > false-positives?
> >
> > It will not tell you which nagios-2.8-4.el5 breaks a dependency chain. 
> > Was it the one from EPEL or the one from RPMforge ? Both have the 
> > exact same release.
> >
> > yum doesn't say, you cannot query it because it is not installed. 
> > Hell, since both have the same filename you won't even know by querying the 
> > repositories.
> > 
> > This is not solvable unless you either improve yum to report all other 
> > information (including keys and/or other tags), which still doesn't 
> > fix all the other tools and is plain confusing. Or if you make the 
> > filename more unique, which is what the repotag does.
> >
> > BTW rpm -qa | grep '\.rf$' is pretty conclusive _if_ everybody follows 
> > the same standard and you require packages to be signed.
> >
> > BTW2 Dissing the repotag usefulness is like dissing the disttag 
> > usefulness. It is as arbitrary, makes the release longer and is in 
> > essence not required. Still it has its use.
>
> First of all: yes, you're right.
> 
> But we will face this issue with EPEL. A repotag will not help to blame
> EPEL when something breaks (they don't have one). It will only help to
> blame RPMForge (as RPMforge has one). 

That's why EPEL should have one. At least until something better comes 
around (if there ever will).

People say a repotag should not be in the filename. But a filename is 
there to identify what it is. The version is there to identify what it is, 
just like the name and the arch. All of these are not required in the 
package name. In fact, rename whatever package you have to "this_package"
(without the arch, without the extension) and rpm handles that fine, 
because it doesn't use the information in the filename, it uses the 
header. So the filename is there for the user to identify what it is.

So what's wrong with having the repotag, like the disttag and like the 
version and name in the filename ? It helps (at least) some people as much 
as all that other information and it solves a practical problem with 
yum/rpm and other tools that cannot give all that other information right 
there when we need it. (and if they would, most people wouldn't understand 
why the signature or an arbitrary string is there the moment you have a 
dependency problem).


> I don't think repotags should be dropped because they suck. I just think
> that they're a workaround for broken/incomplete tools and have been in
> place for too long. Hell, neither rpm nor yum nor anything else actually
> knows there is something like a repotag. They just display it because we
> hijack the package signature.

It is a work around. Why else the disttag ? The repotag is arguably as 
useful as the disttag in the filename. Would you argue against the disttag 
in the same way ? In fact why have the release there at all. And the 
architecture ? Most people don't know what that means anyway.


> People will need better tools anyway, because nobody will be able to
> tell the difference between an EPEL and a base distro package. I think
> yum should actually tell you vendor and distro on all packages.

The problem is, even when you have 'better' tools, how would they present 
that information without filling the screen and actually helping to 
understand the information. The repotag is short and doesn't add as much 
noise as a signature or an arbitrary string would cause.

I don't think it is practically fixable (if anybody would ever care to fix 
RPM and backport it to EL2.1, EL3, EL4 and now EL5 -> NEVER). So whatever 
'better' technical solution you propose, it wouldn't be useful until EL5 
is out of support.

And not to be kidding, we had this discussion when EL3 was released and 
you know what: people also said it was not the correct solution. Do we 
have a correct solution today ? No. Will we have one tomorrow ? No.

So why postpone a solution until we have a better one ? Especially when we 
cannot define what a better solution would look like and we cannot fix the 
tools.


> We already had similar issues on x86_64 where you couldn't tell the
> difference between i386 and x86_64 packages. Today yum reports every
> package with its arch.

Right. So more information is better. How would you ideally present the 
repository info in the output when there's a problem. The repotag is the 
most preferred (read: shortest) way IMNSHO.

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]
_______________________________________________
users mailing list
users at lists.rpmforge.net
http://lists.rpmforge.net/mailman/listinfo/users