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

[Axel Thimm]

On Tue, May 18, 2004 at 08:43:11AM -0300, Alexandre Oliva wrote:
> On May 17, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:
> 
> > Or you pick the same release tag (for example "3") and add a different
> > suffix that will always be rpm-less for FC1 than for FC2 like "fc1"
> > and "fc2". The packages are now called foo-1.2-3.fc1 and foo-1.2-3.fc2
> > and you know that the true buildid is the "3" which can be used in
> > ranged dependencies (Requires: foo >= 1.2-3).
> 
> Oh, that's what you want disttags for?

One of its used, yes (I enumerated some at the start of this thread ;)

> Sorry, but it isn't going to work.
> 
> Consider that FC3 shipped with say foo-1.2-7.fc3.  FC4 will probably
> undergo a few mass rebuilds,

Gotya! One of the other uses for a disttag is tha a mass-rebuild does
not need to bump the release tag of each innocent rpm, but can have
them bumped through the disttag, for example:

fc2.89.103 (the 103rd mass rebuild in fc3 developement)
New glibc gets pushed out, command to rebuild every rpms gets out.
Elliot changes disttag to fc2.89.104, hits a button on the build
system and goes to have some coffee or tee.

This scenario is not science fiction, it already works with the
existing disttag schemes.

But that is "just another use" of disttags.
> I suppose this is going to result in foo-1.2-7.fc3.1, foo-1.2-9.fc4.1
> and foo-1.2-10.fc5 (rawhide), all of them containing the fix.  You
> can't just use the version tag to identify packages containing the
> fix.

If the buggy version was foo-1.2-7, then the fixed is

foo-1.2-8.fc3
foo-1.2-8.fc4
foo-1.2-8.fc4.89.105

The idea is that trivial changes like rebuilds don't even need to bumb
the release tag (or the buildid component).

It does become trickier, if the different distros are based on
different _upstream versions_ and you have a policy of non-upgrading,
but only minimal backports (like RHEL or RHL). While this is not the
usual case with FC's policies, one must admit that this cannot be
fixed with disttags, you have genuine functional forks at differnt
timelines in this case.

Hey, disttags aren't considered the solution to everything, they only
make life easier, but not yet trivial ;)
-- 
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/20040518/533273d4/attachment.sig>