[users] Dropping the repotag

Dag Wieers dag at wieers.com
Sun Mar 18 18:34:29 CET 2007


On Sun, 18 Mar 2007, Andreas Rogge wrote:

> 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.

That's why I am considering dropping it. If it doesn't get added to their 
packaging policy, then I prefer to follow their policy and proof them 
wrong.

It's sad if that will happen, but it's the only way to make them 
understand what is at stake. As long as other repositories add a repotag, 
EPEL will not need one. So I'm forcing them to consider needing one. If 
only to play nice.


> > 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).

Same for name, version and release. They are not required and could 
therefor be removed from the filename. At some point in the past SuSE 
didn't have version and release tags in their RPM filenames.

The directory listing were slimmer :)


> > 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.

Again, what useful solution are we talking about ? Because having the 
repotag and disttag in the header will add anything significantly. The 
advantage is to have it in the filename for various reasons that having it 
in the header will not solve.

Sure it would be nice to have it removed from the release tag. But then 
again, there's not harm having it there either. So whatever solution is 
better, they are cosmetical, not technical nor functional.

The repotag is a functional solution.


> > 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.

Right, a solution that we cannot use now and not for the next 7 years :)


> > 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?

Feel free to bring one up that is clearly better. And if possible can be 
used with older releases as well.

We do want it to be in the filename, we don't want it to be long. You'll 
end up with a repotag. Whether part of another header or part of the 
release tag is of little relevance.


> 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.

At that point I do not care. I follow Fedora policy and ask people to file 
bugs against yum :)


> 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.

Tell me by what and for what reason ?


> > > 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.

It is not redundant data if it has a clear use.

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]



More information about the users mailing list