Axel Thimm Axel.Thimm@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