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. ,= ,-_-. =.
> b...@iguanasuicide.net ((_/)o o(\_))
> ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
> http://iguanasuicide.net/ \_/
Thanks for all the details.
CJ
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
