Disttags are nice, save the disttags

[Axel Thimm]

On Tue, Jun 05, 2007 at 02:59:15PM +0100, Jonathan Underwood wrote:
> On 05/06/07, Axel Thimm <Axel.Thimm at atrpms.net> wrote:
> >You misunderstood the building twice:
> >
> >a) first against the current rawhide
> >b) then against the result from above
> >
> >so you would have emacs-vm and emacs-bbdb already in pass a)
> 
> Nono - I think I understood... The point I was making was that between
> your (a) and (b), to get all functionality, a change to one of the
> spec files would be required.

You mean for the case that the elisp sources moved between emacs
releases? Yes, that's true, but in that case you *have* to rebuild
both in whatever fashion anyway, this is no longer a nice-to-have
rebuild. :)

Same will be true for perl/python/etc modules when suddenly the paths
change (although less for perl). But all these core upgrades in
rawhide always require all the dependent package to be rebuilt, in
fact the packages are then usually just broken (e.g. depending on a
non-existing python abi and the like).

The proposed mass rebuilds assume that the rawhide pool of package is
in some sane state already, it is not assumed that we change the
development model to throw anything against rawhide and have the
mass-rebuilds comb the issues out. :)

Or rephrased otherwise: The mass-rebuilds should ensure that the
packages really see the same build environment and that their builds
are really reproducible. If the claims that the state of the tree at
that point in time is sane are really true, then they will just burn
some CPU cycles, and the QA after this will not find anything, so
Jesse will say "told you so, all is fine", and we'll believe him, as
proof was given. ;)

But we'd also have the case were some packages suddenly find that the
changes from kernel-devel-2.6.18 to 2.6.21 are that big that they'd
rather break on the rebuild or offer different, more appropriate
functionality. Like for example when PAGE_MASK or other userland
header bits are suddenly missing.
-- 
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-maintainers/attachments/20070605/8ad40448/attachment.sig>