[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Building in chroots



Eduard Bloch <edi@gmx.de> writes:

> #include <hallo.h>
> * Frank Küster [Tue, Aug 01 2006, 01:55:14PM]:
>> md@Linux.IT (Marco d'Itri) wrote:
>> 
>> > On Aug 01, Eduard Bloch <edi@gmx.de> wrote:
>> >
>> >> > > Also, pbuilder and debootstrap are considered absolutely critical for
>> >> > > serious work.
>> >> > That's a bold statement.
>> >> Are you serious? (SCNR ;-)
>> > Yes. I do not use either and I think I have been doing serious Debian
>> > work so far.
>
> Argh, the smiley was there for a reason...
>
>> > Building in chroots *hides* bugs.
>> 
>> Of course.  However, not building in chroots also hides bugs.  Why do
>> you think it's better to build in a chroot?
>
> After all, I think after comparing pros and cons the bill will be even.
> But at much higher processing costs. I am sceptical about pbuilder
> because of it, and because it leads to too much thrust into the tool
> instead of thinking about possible consequences of changes.

Yeah.

I always develope outside (or in an unclean) chroot and when I want to
release I mangle the source through a clean chroot / buildd again for
a final test.

>> I think a package should be built on the developer's system (which,
>> hopefully, is a typical example for the environment were the package
>> will be used and built), and in a clean chroot.  It should be tested (in
>
> I think it should be working in both, therefore I like the general
> concept of building in normal environment and uploading package as
> source trough the auto-builder.

That won't test your binary-all target as small as that part is.

>> the sense of: Can it be installed?  Does it run at all?) in a chroot,
>> and also on the developer's system.  Of course the amount of testing
>> needed depends on the extent of the changes.
>
> Testing is not always enough to catch all possible bugs.

But not testing is a sure way to overlook them. :)

> Eduard.

MfG
        Goswin



Reply to: