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

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 ..
> >     . build-dep ..
> >     . debuild ..
> >     . dpkg -i ..

> 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
> also "dirties" your system with the Build-Depends of the package.
> 
> _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.

I did look for a document that would attempt to put the different tools
into perspective and I was not that surprised to come up empty-handed
since it would be a rare individual indeed who has used all of them and
would be able to recommend one best adapted to your needs.

> It will also isolate the build process into a chroot, so that you
> won't inadvertently forget to list a Build-Depend that you just happen
> to have installed and won't have Build-Depends installed on your
> running system (which I think is good).

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.

> 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?

> > One problem, though, is that since the build is pretty much
> > automated, I'm not sure how I could add --xxx configure options that
> > override the defaults. In particular after reading the man page I
> > wasn't able to find an option that would let me achieve this.

> As with others, I'll just point you at the debian/rules file.  That's
> the starting point for the build process, so it will normally be your
> starting point.  Depending on the package, there may also be a file
> describing the build process and how to modify/maintain it.  If so,
> read that along-side the debian/rules file.

Thanks, I would probably have missed that.

> Trying to modify the build process without reading and understanding
> (at some level) the debian/rules file is similar to trying to modify
> the build process of a project that uses a plain Makefile without
> reading that.
> 
> > Another concern is what kind of naming standard I should/could adopt
> > for my custom .debs so that they integrate smoothly with the apt
> > packaging system. In other words.. in a way that will be easy to
> > manage over time and not interfere with possible future apt-get
> > actions, such as upgrades to a new release etc.
> 
> As other have mentioned, using a different version instead of a
> different name will allow clean upgrades.  The normal way to do this
> is "${debian_version}yourname0" for the first private version, then
> increment the number at the end for each subsequent private version
> based on the same Debian version.  E.g. 1.2-2 -> 1.2-2yourname0.
> 
> If you'd prefer your package *not* be upgraded when there is a new
> Debian version, but *be* upgraded when there is a new upstream version
> you could use "${upstream_version}+yourname0-${debian_suffix}", e.g.
> 1.2-2 -> 1.2+yourname0-2.

Not to mention that at some point or other there may be cases where I
need different versions of my custom packages.

> In both cases you can use "holds" or apt_preferences(5) to prefer your
> version over the newer version.
> 
> If you'd prefer your package to not be upgraded at all, you should
> rename the package and then have your package Provides the old package
> name.  This may not work seemlessly if there are versioned Depends of
> the old package name, but should work well, especially if you continue
> to follow the Debian conventions for package versioning, e.g. by using
> one of the previous two paragraphs to guide your version numbers.
> 
> IIRC, devscripts has a script/program to compare version numbers if
> you aren't sure which one the "newer"/"greater" than another.

> -- 
> Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
> bss@iguanasuicide.net                     ((_/)o o(\_))
> ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
> http://iguanasuicide.net/                      \_/     

Thanks for all the details.

CJ


Reply to: