[users] Dropping the repotag

Andreas Rogge a.rogge at solvention.de
Sun Mar 18 18:16:37 CET 2007


Am Sonntag, den 18.03.2007, 14:37 +0100 schrieb Dag Wieers:
> 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).
Yes, but you cannot force epel to add one. So we have to find our way
around this.
> 
> 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.
> 
Yep. In fact it would be best to *always* have a dist and a repo tag (or
disto and vendor tag, call them what you want). I don't even argue that
it must be removed from the filename - I just don't need it myself and
it is not required for proper operation.
What I actually argue is that using the revision tag for it sucks. You
can write arbitrary strings into the revision and these repotags are not
required and they are only line noise to the package manager (same for
disttags).

> 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.
Yes, I would argue against the disttag with exactly the same arguments.
It would all be fine if these "tags" were actually a real information
that's known to the underlying tools. This would also force people to
fill this information (and we wouldn't argue here, because EPEL packages
would contain these tags).
For architecture all is well. It *is* a structured field from inside the
package that rpm actually uses and putting it into the filename is
required for normal operation (kernel-packags for i586 and i686 have to
live in the same directory). And *every* package has an architecture
set. Even "noarch" is a worthy information.

> 
> > 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.
Point taken.
> 
> 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.
But unless we start to move something now, we will never have a useful
solution, not even after EL10 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.
And I *hope* that EPEL will arise enough issues so that they're either
fix the tools and provide a working solution or they add repotags to
their packages.
> 
> 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.
Why stick to a solution if we could develop a better one?
I fact I'm not trying to make you remove the repotags. But if you do (no
matter what your reasons are) we have to discuss what we will do once
they are gone.
In fact I never liked repotags neither did I like disttags. Even if they
are a good workaround, they should have been replaced for years.
> 
> 
> > 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.
Point taken. This is an issue because the vendor and dist tags contain
too much text. I just proposed them because I hate redundant data.

kind regards,
Andreas Rogge

-- 
Solvention systems management
Egermannstr. 6-8
53359 Rheinbach

Tel: +49 2226 158179-0
Fax: +49 2226 158179-9

http://www.solvention.de
mailto:info at solvention.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3219 bytes
Desc: not available
URL: <http://lists.repoforge.org/pipermail/users/attachments/20070318/655c96f7/attachment-0004.bin>


More information about the users mailing list