repository- & disttag order

[Axel Thimm]

On Sun, Jan 11, 2004 at 06:06:47PM +0100, Enrico Scholz wrote:
> 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?

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 at physik.fu-berlin.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040111/3a09cc8d/attachment.sig>