On Wednesday 2008 December 31 18:45:26 Chris Jones wrote: > What I have done so far is pretty much what is describe 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).
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).
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.
> 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.
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.
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 conpare version numbers if you aren't
sure which one the "newer"/"greater" than another.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
b...@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
signature.asc
Description: This is a digitally signed message part.
