On disttags (was: Choosing rpm-release for fc1 and fdr add-on rpms)

[Axel Thimm]

On Wed, May 12, 2004 at 08:01:24PM -0300, Alexandre Oliva wrote:
> On May 12, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:
> > So the release tag looks like
> 
> >    <buildid><distid><distversion><repotag_opt>
> 
> > where buildid shound end with digits (for example a simple integer
> > like "3", or something conatining cvs info like "0.cvs20040512.16"),
> > distid should be invariant for the family of distributions and
> > distversion should be rpm-sortable (7.3, 8.0, 9 for instance). Repotag
> > is placed at the least significant place wrt to rpm comparison and is
> > optional.
> 
> > Nobody objected this scheme above
> 
> I thought there was some minor opposition.  <buildid> should *always*
> start with `0.', such that, whenever the distro contains the same
> version of the package, starting with 1 or above, the version in the
> distro is used.  If you build multiple times, use 0.1, 0.2, etc.

The scheme above abstracts hierarchical buildid into simply
<buildid>. It was also proposed for Fedora Core packages, too, not
only for 3rd party repos.

When we introduced the zero-prefix one and a half year ago, it was
done in the assumption of a lack of communication with the higher
hierarchy (the vendor).

IMHO in the Fedora context the communication is starting to become
bilateral and such safeguards are less an issue. Packages proposed for
submission from 3rd party repos into FC have been accompanied by a
coordination of the 3rd party repo and the Red Hat insider ensuring
proper upgrade paths (which is more than only the versioning).

> My actual preference would be to instead use:
> 
>      0.<distid><distversion><repotag_opt><buildid>

In hierarchical buildid the 0 is used when the version is higher than
that of the vendor (or higher hierarchry). If the updated package is
based on the same upstream version like the vendor's you need to use
the vendor's buildid as the prefix.

Buildid at the least significant position? That would make it less
important than the "random" repotag, e.g. the scheme above would be
valid only within one repo and one dist.

Suppose you have

	foo-1.2.3-4.rhfc1.blah.i386.rpm
	foo-1.2.3-4.rhfc2.blah.i386.rpm

A security errata lets you roll out

        foo-1.2.3-5.rhfc1.blah.i386.rpm
	foo-1.2.3-5.rhfc2.blah.i386.rpm

In this scheme you know that both fc1 and fc2 will have the fixed
version, even when the fc1 box decides to upgrade.

In the case of

	foo-1.2.3-rhfc1.blah.4.i386.rpm
	foo-1.2.3-rhfc2.blah.4.i386.rpm

and

	foo-1.2.3-rhfc1.blah.5.i386.rpm
	foo-1.2.3-rhfc2.blah.5.i386.rpm

The broken version of fc2 (4) will have a higher significance for rpm
than the fixed for fc1 (5).

So the buildid (however composed, hierarchical or containing
subverision information and so on) should be placed first in the
release tag, the repotag last (as it should not be involved in
comparisons) and the disttag can only be placed in the middle. ;)

> >> >Conversely, all seem to be designed "to take over the system".
> 
> > Even though this is our secret obsession, what do you man by that? 
> 
> Dunno what he meant, but IMHO external repositories should be split
> into Extras and Alternatives, where Extras contain packages that add
> to the system without replacing any of its core components, leaving
> replacing/upgrading to Alternatives.

I can only speak for the packages I have been upgrading, which are
mostly upgraded for enabling other packages either in build
dependencies (make, automake, autoconf) or in runtime
dependencies. The consistent approach would be to pull packages
depending on Alternatives into Alternatives themselves, so soon there
would only be packages in Alternatives.

In general I don't see what purpose Alternatives would have. Users
would have the (false) feeling of a more stable system by not using
them, as no core packages have been replaced, but a couple of dozen
kernel module rpms and daemons can destabilize and insecure your
system far more than an updated package.
-- 
Axel.Thimm at ATrpms.net
-------------- 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/20040513/d05f4e65/attachment.sig>