Axel.Thimm@physik.fu-berlin.de (Axel Thimm) writes:
reptag at the end causes ambiguities. You can not say if '1.1.1.foo' means versions 1.1 for FC1, or if it means version 1 for FC1.1.
That's why it was argumented (among others) that the disttag needs to start with letters like
-1.1.rhfc1.es -1.rhfc1.1.es
Seems that this needs an extra discussion. But for my taste, 'rhfc' is bit too long and shorter alternatives will destroy the updatepath.
No ambiguity possible.
With 'V.R.D' naming scheme (e.g. '-1.es.1.1') this would be no issue neither...
Larger release numbers win over newer distributions.
Same with V.R.D...
repotag before disttag is the only way which makes sense; see
This breaks the use of disttags for ensuring distribution upgrade paths.
1.foo.1 < 1.foo.1.1 is still the correct update-path.
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. Using it as an ordering parameter would not be wise. %release can be compared within the same repository only, but not between repositories.
E.g. if to take '10.foo.rh9' or '1.bar.rh9' can not be determined by %release; it can mean that foo's packager is a bloody beginner who needed ten tries to make it built, and that '1.bar.rh9' was written by a packaging god who succeeded at the first try.
Enrico