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

[Axel Thimm]

On Wed, May 19, 2004 at 01:27:40PM -0300, Alexandre Oliva wrote:
> On May 18, 2004, Rex Dieter <rdieter at math.unl.edu> wrote:
> 
> > On Tue, 18 May 2004, Alexandre Oliva wrote:
> 
> > Besides, the case you mention case easily be avoided.  *Always* use the 
> > same # of significant digits/dots in front of dist tag and/or simply 
> > increment the release, so you end up with either
> > -1.0.foo -> -1.1.foo
> > or
> > -1.foo -> -2.foo
> 
> >> If you use disttags, and you have to patch a package such that the
> >> R number goes in between two R numbers that are already out, and you
> >> can't just append the build number at the end for the reasons Axel
> >> already exposed, and you can't add `.number' before the disttag, what
> >> do you do?
> 
> > No problem.  (-:  Migrating *to* disttags actually helps in this 
> > case, and you avoid the problem you mentioned above because there is no 
> > existing dist_tag.  Example, foo-1-3 and foo-1-5 are released now.  
> > Release patched version as:
> > foo-1-3.0.%{dist_tag}
> 
> How about foo-1-3.fc3 and foo-1-4.fc4
> 
> How do I issue an errata for fc3?

If foo-1-4 is already fixed, e.g. needs no errata, then you must fork
the buggy foo-1-3 into decimals, to place it before foo-1-4,
for example foo-1-3.1

So you get with added disttags:

foo-1-3.fc3
foo-1-3.1.fc3
foo-1-4.fc4

in rpm's sort order.

> 3.1.fc3 (or 3.0.fc3?) won't work, because it causes numbers to be
> compared with letters.

Only for non-updated Red Hat 8.0 and before, which means that your rpm
database is anyway out of order at every second install. So, we can
assume a working rpm.

> 3.fc3.1 won't work because upgrading to 4.fc4 will go backwards (I'm
> not sure I buy that, but it's not my argument, it's Axel's).

Well, would you prefer a buggy/insecure version built for fc4, or the
fixed one for fc3, but built against an older glibc? This preference
defines the rpm sort order you are going to give to the errata
packages.

E.g. you either fix both (if both versions are vulerable) separately
to
foo-1-3.1.fc3 and
foo-1-4.1.fc4

or you release a common erratum like
foo-1-5.fc3
foo-1-5.fc4

You still have both choices.

As you noted (I mean Alexandre), there can be a problem with letters
and numbers mixing, when the _number of_ the segments before the
disttag change (like being done for forked timelines).

But this is only for a buggy rpm. If we would really want to be safe,
we shouldn't also use comparision of equal substrings, e.g. "1" vs
"1.1", as this had been another (older) rpm bug.

We do need to define some basic functionality for rpm to be able to do
anything with it, and IMHO we can and should assume the letter/numbers
mixing bug as fixed.

Otherwise all of fedora.us would suffer from this, as there the
disttags from RHL to FC jumped from letters and numbers. And obviously
this issue has not been observed too often.

Disttags are good, not evil :)

Persuaded? If yes, how many disbelieving Red Hat developers are there
to continue? ;)

If not, let's go on with the discussion in half a year, perhaps the
merger with fedora.us will increase the necessity for disttags.
-- 
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/20040520/280a906b/attachment.sig>