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

[Axel Thimm]

On Tue, May 18, 2004 at 04:01:22PM -0300, Alexandre Oliva wrote:
> On May 18, 2004, Axel Thimm <Axel.Thimm at ATrpms.net> wrote:
> 
> >> 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
> 
> All of the above had the bug and have to be fixed, and -8 won't do it
> for them.

No, there would not have been the -9 and -10 versions (because the
rebuilds are controlled via the disttag).

Otherwise use "11" instead of "8".

> > The idea is that trivial changes like rebuilds don't even need to bumb
> > the release tag (or the buildid component).
> 
> That's good.  But it still doesn't cover the case of patches being
> added to the package, which is what got foo-1.2 bumped from -7 to -9
> between FC3 and FC4.

I still believe in common specfiles and src.rpm, so I would make the
application of patches conditional on the disttag, or the environment
probing, e.g. apply ntpl patches only if built on an ntpl platform.

And if that is not an acceptable solution, well, disttags cannot solve
everything for you, you've got to do also something ;)

The bottom line is disttags bring a lot of benefits as can bee seen in
their implementation in the wild, have caused no harm, and come at
very little expense.
-- 
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/31c9e668/attachment.sig>