On Tue, Jun 05, 2007 at 02:59:15PM +0100, Jonathan Underwood wrote: > On 05/06/07, Axel Thimm <Axel.Thimm@xxxxxxxxxx> 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
Attachment:
pgp7eTCBAaBkf.pgp
Description: PGP signature
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
