Re: Using buildds only
Wouter Verhelst <wouter@debian.org> writes:
> On Tue, Aug 23, 2005 at 09:54:20PM +0200, Goswin von Brederlow wrote:
>> Wouter Verhelst <wouter@debian.org> writes:
>> > 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.
>
> In my experience, it's not that bad. Last time I manually upgraded
> anything inside the chroot must have been about two or three months ago.
> Yet it failed a number of packages due to a bug in glibc 2.3.5-3 which
> made libraries break on kernels without NPTL support (such as the 2.2
> kernel which is running on that system). This particular bug also hit
> q950 and tanda, two of our other buildd systems.
>
> Considering glibc was uploaded to the archive on August 5th (or at
> least, the katie mail was sent out at that time), that I started
> noticing this bug about a week ago, and that it probably took about a
> day for the new glibc to be built on m68k and uploaded by the buildd
> (but I can't check that, debian-devel-m68k-changes doesn't appear to
> have worked since 2003), that leaves about ten days for the package to
> be installed after it was available.
>
> Manual maintenance wouldn't have made that go much faster, if at all;
> and the way glibc got upgraded in this particular occasion is far from
> exceptional.
>
> Anyway, this is of course all moot for me particularly since LVM doesn't
> work on 2.2, and 2.6 doesn't work reliably on all m68k macs yet either.
> But at least we're getting places in that area already :-)
The reason glibc was installed is probably quite simple: Some
Build-Depends was build against it (on another buildd) and when it got
installed the Depends line pulled in glibc.
Anyway, point is that you have to check, clean and update the chroot
every so often now too. Having the chroot get remade automaticaly
sometimes saves some cleanup runs for the cost of more upgrades. I bet
that part doesn't give or lose anything.
But misbuilds caused by a failure to remove packages, especialy ones
that leave the chroot in a state where apt/dpkg keep failing, would be
avoided that way.
And don't forget that you don't need lvm, it is just one option. The
fastest one I believe but a simple rm + tar will do just as well.
MfG
Goswin
Reply to: