[users] Dropping the repotag
dag at wieers.com
Sun Mar 18 14:37:12 CET 2007
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 is 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
> 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
> 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.
-- 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 users