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

Re: Debian etch - Rebuilding a package from source.



On Thursday 01 January 2009, Chris Jones <cjns1989@gmail.com> wrote 
about 'Re: Debian etch - Rebuilding a package from source.':
>On Wed, Dec 31, 2008 at 11:16:46PM EST, Boyd Stephen Smith Jr. wrote:
>> On Wednesday 2008 December 31 18:45:26 Chris Jones wrote:
>> > What I have done so far is pretty much what is described in the
>> > above:
>> >
>> >     . apt-get source ..

You might also look at apt-src.

>> >     . build-dep ..
>> >     . debuild ..
>> >     . dpkg -i ..

I go ahead and maintain a local apt repository (using apt-ftparchive) and 
then use aptitude to install, but dpkg -i is fine.

>> I'll go ahead and disagree with the others, slightly.  This is fine
>> for packages you are only going to use yourself, or only install on a
>> system with the same packages installed as your current system.
>>
>> _It_ _will_ _work_ and the packages that come out will be completely
>> valid.  However, making a pbuilder(cowbuilder) environment will make
>> sure your packages build from source cleanly, and only depend on
>> packages available from a specific flavor of debian (Etch/stable,
>> Lenny/unstable, Sid/unstable).
>
>Yes, I also saw pbuilder/cowbuilder mentioned in several places.
>
>I also ran into dh-make and dpkg-buildpackage, and though I did not go
>into details in my initial post, the existence of such a variety of
>tools is the main reason I posted here.

For me, debuild was easier than dpkg-buildpackage and I've never used 
dh-make.  Heck, the first time I built a debian package from source I 
used "make -f debian/rules binary" because I hadn't read any documentation 
and was just poking around.

pbuilder/cowbuilder are mainly a system for managing the chroots and use 
dpkg-buildpackage for building.  pbuilder also comes with debuild-pbuilder 
that uses debuild for building instead of dpkg-buildpackage.  
debuild-pbuilder is my current tool of choice.

>> It will also isolate the build process into a chroot,
>
>Sounds like a very useful feature but then since debian-live also builds
>its target in a chroot, I'm beginning to wonder whether it provides some
>way to integrate custom deb's that I have overlooked.

That may be the case.  I do not currently have any experience with 
debian-live, so I couldn't usefully comment.

>> If packaging is just a means to an end, skip the pbuilder for now.
>> However, if you want to make high-quality package that might be
>> accepted into Debian, a pbuilder environment is a must.
>
>What would the tradeoff be? Is it a matter of a steeper learning curve?
>Does it require more resources such as disk-space?

Yes, a bit steeper, mainly just because you'll be adding yet another tool 
to your toolbox.

Yes, you'll need enough persistent disk-space for a base Debian system that 
will reside (possibly compressed) in /var/cache/pbuilder.  During the 
build, the chroot will grow as it will be uncompressed, if compressed, and 
download and install all the Build-Depends and of course there is the 
build process itself.  You'll need enough disk space for this processes, 
but after the build is complete most of this disk space will be reclaimed.  
What is not reclaimed is the downloaded package files which will be put 
into /var/cache/pbuilder/aptcache so that later pbuilder invocations will 
not have to re-download those packages.

I currently have 3 2-month old pbuilder chroots (Etch/Lenny/Sid) 
and "du -sh /var/cache/pbuilder" reports 793M.
-- 
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss@iguanasuicide.net                     ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.net/                      \_/     

Attachment: signature.asc
Description: This is a digitally signed message part.


Reply to: