Repotags do have meaningful version information (was: repotags proposal)

[Panu Matilainen]

On Wed, 23 May 2007, Dag Wieers wrote:

> On Wed, 23 May 2007, Dag Wieers wrote:
>
>> On Wed, 23 May 2007, Tim Lauridsen wrote:
>>> Panu Matilainen wrote:
>>>
>>>> My 5c on the topic I've been trying to avoid because it's too flammable for
>>>> my taste. I hate politics so I'm not going to get into that, I'm commenting
>>>> from purely technical POV, and actually have a proposal that might make them
>>>> unnecessary.
>>>>
>>>> Repotags as part of release string are just plain wrong. Unlike disttag, the
>>>> repotag does not have a meaningful version information in it, it's really
>>>> just a fuzz-factor to somehow differentiate packages coming from different
>>>> places.
>>
>> It does have meaningful version information in a multi-repository world.
>> It shows what version of the package you have. rf means this is the
>> RPMforge version. It makes the package/filename/version unique !
>
> -snip-
>
>> Especially when packages from different repositories have the same NEVR,
>> similar sub-packages and have dependencies between them.
>>
>> The clamav package is a nice example. Without repotags, dependencies would
>> exists between packages from different repositories.
>>
>> Saying that repotags have no meaningful version information is very wrong.
>> It makes the system work.
>
> For everybody involved, please read the above again.
>
> Most people object to repotags because the repotag does not have any use
> in the version comparison. That's right, it does not.
>
> But it *does* affect dependencies when there is no identifier in the
> version/release information. Particularly when there is more than one
> repository.
>
> So it is indisputable that it is meaningful in the version information,
> because without it RPM would fail to resolve dependencies in a correct
> way.

Ah, a good point which I didn't think of at all, sorry about that. I was 
only talking about version information in the "newer/older than another 
package of same name" sense.

Yes, repotag-in-release allows sub-package dependencies to be expressed in 
a way that prevents accidental mixing of sub-packages of same name from 
other repositories. It would be of course possible to express that by 
using additional virtual provides-requires pairs but that adds a fair bit 
of manual work for little or no gain.

Repository namespaces would help :) But the root issue here I think is 
that sub-packages often should and could have a stronger dependencies 
on each other than the typical "Requires: %{name} = %{version}-%{release}".
In other words, one would want the sub-package dependency to only match 
packages originating from the same *build*. Something like "Requires: 
%{name} = %{buildid}" where the build id is a hash computed from version, 
release, arch, buildhost, buildtime plus possibly bunch of other things, 
and automatically injected into provides.

> This was brought up at least 3 times in the previous discusisons. You see
> why it is frustrating when people keep on objecting but loose half of the
> information that was provided. Why we have to repeat. Why Axel gets tired.

It's just that the actual issues tend to get lost in all the noise. At 
least I haven't had the stamina to read through all of the repotag 
discussions, because the "to repotag or not to repotag" question itself is 
totally irrelevant and uninteresting to me. The actual problems, not the 
bandaid, is what I'm interested in.

 	- Panu -