Disttags are nice, save the disttags

[Axel Thimm]

On Tue, Jun 05, 2007 at 10:01:32AM -0400, Jesse Keating wrote:
> On Tuesday 05 June 2007 09:39:27 Axel Thimm wrote:
> > No, you also got it wrong. I'm not talking rebuilding from scratch,
> > but against rawhide. That's what all mass-rebuild were like until now.
> >
> > Both rebuilds will succeed (unless there is a bug in the package and
> > that would be good, so we can fix it): the first one will have
> > buildrequires from FC6->F7 since that's what the repo looked like, the
> > second will have fresh buildrequires from the previous pass. No need
> > to look at N-folded-recusion.
> 
> You're still not getting it as well.  Are you talking about building one 
> package a day so that said rebuilt package is assured to be in the buildroot?  
> If you rebuild A, the rebuilt A (well call it A.1) isn't available in the 
> buildroot for another 20+ minutes.

No, no waiting for the results, these are used in the second
pass. Only one createrepo between the two mass-builds.

> Quite a bit more if there are 4K other builds queued up.  So B which
> is next on the list rebuilds against the old A, not A.1, C rebuilds
> against B, not B.1, D against A, and B, not the .1's.

Correct all packages from the first pass build against the snapshot of
what was just before the mass-rebuild.

> The next time you build, you get A.2, B.2 rebuilt against A.1, C.2 rebuilt 
> against A.1 and B.1 (which is still a build against A, not A.1), so on and so 
> forth.

Correct.

> The only way to ensure that everything is up to date is to insert
> delays inside the chain (using something like chain-build) so that A
> builds to A.1, pause for it to be in the buildroot, B rebuilds
> against A.1 to become B.1, pause for it to be in the buildroot, C
> rebuilds against B.1 and A.1 to become C.1, etc...  This is just one
> chain, there are /many/.

Why should that be neccessary? Unless the state of the tree is that
bad, that the ABIs toggle around during the rebuild, you will end up
with the proper interfaces after the first pass already and that's
what counts.

If you claim that the state of the tree will be that bad that this
will not be the case, then you are giving the best arguments to
mass-rebuild early, mass-rebuild often.

But the point is that if you already assume the tree to be sane and
would rather not do mass-rebuilds just out of the fun of
mass-rebuilds, then according to this logic you wouldn't even need a
two pass mass-rebuild, but only a single pass mass-rebuild. And the
ordering would also not matter to you in this case, since the
resulting packages are assumed to be as good as the starting ones.

That would be fine with me as well, I just mentioned the two pass
rebuild scenario because you or someone else started mocking on build
orders.

In a nutshell: If build orders are an issue then the tree is in
desperate need of a rbeuild anyway, no matter what the method, if not
then scheduling a mass-rebuild at least once per development cycle
won't hurt either.
-- 
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/e9a20583/attachment.sig>