Wouter Verhelst <[EMAIL PROTECTED]> writes:
> On Tue, Aug 23, 2005 at 11:25:41AM +0200, Marc Haber wrote:
>> On Tue, 23 Aug 2005 01:42:18 +0200, Martin Pitt <[EMAIL PROTECTED]>
>> wrote:
>> >Something like this is in fact considered. Probably Ubuntu won't use
>> >pbuilder itself since it is not the most efficient implementation
>> >around, but rebuilding the buildd chroots from scratch would help to
>> >eliminate many FTBFS bugs due to polluted chroots.
>>
>> Surely you are aware how much time it takes to rebuild a chroot on
>> slower architectures. Some technology able to restore a large
>> directory tree to a static default in short time should be used here.
>>
>> I am not sure whether LVM (have a LV with the master chroot image,
>> make a snapshot, build inside the snapshot, remove the snapshot) could
>> help here.
>
> Then you'd have to keep the master chroot image up-to-date. If you don't
> do that, after a while the master image will digress too much from the
> actual Debian archive, and you end up with spending loads of cpu time
> upgrading the same packages over and over again after each build.
You have to keep the chroot up-to-date manualy anyway as sbuild does
not upgrade unless a Build-Depends requires a newer version
specificaly.
> I've been told the amd64 people have implemented something similar in
> the past, but I'm not sure I like that approach.
I've even gone so far to automate upgrading the master image by first
upgrading a snapshot, then testbuilding a smaller package and only on
success do the same to the master.
A simple "touch UPGRADE-MASTER" will perform this automaticaly after
the current build finishes. Very helpfull thing.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
