On Sun, Jan 11, 2004 at 06:06:47PM +0100, Enrico Scholz wrote: > 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? Maybe, because it is build for FC5 at the end of 2005 instead of the version for FC1? > > 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. So make it order insiginificant and move it towards the end of the release tag, maybe that far, that it drops off. > >> 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. There are quite valid reasons (and welcomed, too) for packages being overridden by other repositories, for example o if a first tier repository is only allowed to ship a crippled version of some software for whatever reason (patents, non-OSS components disabled, etc.), as well as o if a package in a repository will not be maintained anymore like products reaching their EOL, o you need a fast security update, o you build a custom repo with custom modification (where this repo could even be private in a company), o possible more reasons, just check all existing repos, all have had an upgrade of some base component for one reason or another. Back to the the core matter: As placing the repotag in front of the disttag only obstructs things, please don't suggest it. Place it after the disttag or drop it. My suggestion for specs: Make it an optional suffix to relase tags: releasetag := <build>[.<disttag>][.<releasetag>] (for completeness sake disttag is also flagged as optional as some packages like firmware packages can be safely assumed cross distribution valid). -- Axel Thimm physik fu-berlin de
Attachment:
pgp00068.pgp
Description: PGP signature