repository- & disttag order

[Enrico Scholz]

Axel Thimm <Axel.Thimm at physik.fu-berlin.de> writes:

>> > Larger release numbers win over newer distributions.
>> 
>> Same with V.R.D...
>
> Yes, but only within a repoid world, not accross different repoid,
> e.g.
>
> 	-1.1.es.rhfc5 loses over
> 	-1.1.fdr.rhfc1
>
> which is clearly not what you want if you are considering more than
> one repo.

Why should the 'es' package win over the 'fdr' one? The right behavior
would be that on updates the 'es' package will be installed when the
old package is an 'es' one, and for 'fdr' vice versa. But this is not
supported by current rpm/apt/yum/... tools so mixing of uncoordinated
repositories needs manual intervention (e.g. apt-pinning) and it does
not matter if repotag is before or after disttag.


> If OTOH you are defining this for a non-repo-mixing world like
> fedora.us, you don't even have to add a repotag ...

It is used there for informational purposes, and it should not be used
for other ones.


>> > Pulling the repotag in front of the disttag obsoletes its use as an
>> > order parameter, which is a bad thing.
>> 
>> Why? repotag is for information only.
>
> Exactly. That's why it should get the least significant ordering,
> i.e. must be last.

No, when used consistently, the position of the repotag does not
matter for ordering and it should be set based on other criteria
(like unambiguousness).


> It would be better for it to not be considered as an order parameter
> at all, but that would mean pulling it into the name or dropping in.

I vote for latter option; Jeff Johnson mentioned that the DistURL: tag
might be used for similar tasks but there are no proposals how to
integrate it in into current tools (apt/yum).

Perhaps the disttag should be disappear too and highlevel tools like apt
and yum should decide based on DistURL: whether package is to be updated
on dist/repo change or not.


>> Using it as an ordering parameter would not be wise. %release can be
>> compared within the same repository only, but not between repositories.
>
> There _are_ some repositories coordinating. Why throw that away?

When coordinated repositories are having distinct packagesets, this whole
discussion is unneeded. Having overlapping packagesets is duplicate work
and sounds like russian roulette to me: the most modified package wins
which might be either a sign of good maintainership, or of unability to
make it working.




Enrico