[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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

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

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 !


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

So it is indisputable that it is meaningful in the version information,
because without it RPM would fail to resolve dependencies in a correct

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 -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]