On Tue, May 18, 2004 at 04:01:22PM -0300, Alexandre Oliva wrote: > On May 18, 2004, Axel Thimm <Axel.Thimm@xxxxxxxxxx> 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
Attachment:
pgpp8B7r5PZt3.pgp
Description: PGP signature
