repository- & disttag order

[Axel Thimm]

On Sat, Jan 10, 2004 at 03:03:06AM +0100, Enrico Scholz wrote:
> Axel.Thimm at 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.

Well, I started this discussion back in September leading to long, but
yet starving threads. Check the archives for upgrade paths or disttags
in the subject. There is also the same discussion on fedora.us from
March/April.

> > 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...

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

> > 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. 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. The former is insane, the latter would be better
than putting in front of the disttag.

> 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?

There are no benefits in doing it repotag in front of disttag, but
there are doing it the other way.

> 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.

foo's packager could have as well upped the Epoch and done lots of bad
things to destroy both package contents, as well as upgrade paths.

The release buildnumber should alway win, second should come the
disttag, in case the same build has been performed for verious
distributions of the same upgrade line. repotag is order insignificant
and should, if at all, only be placed last.

Personally I wouldn't mind seing repotag dissapear. There are other
way identifying the origin of a package. But it doesn't hurt either
(unless you write your full name in there and come from Spain ;).
-- 
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/20040110/34464f80/attachment.sig>