Repackaging a Debian package for use with Breezy
sistpoty at ubuntu.com
Mon Feb 20 21:35:23 GMT 2006
(moving to ubuntu-motu list, as I think this is a better place for this
Am Montag 20 Februar 2006 21:00 schrieb Andrew Conkling:
> Hey Stefan, thanks for the reply.
> I didn't even think to check if it would be added; that's great to
> hear! (It also spurs me on to get a few things worked on so that the
> version in Dapper would be even more stable and usable. :)
Great... however there is not really time left even for dapper to bring new
versions in, since we are already in UpstreamVersionFreeze. That means, that
we need to ask for an exception for all newer upstream versions and of course
need a good reason for it (like fixing bugs).
> I understand that it can't be added to Breezy, but all the same, I
> would like to create a package for Breezy that I can host on the
> website (and install for my own use). I guess you could consider it
> an exercise in package creation and edition. I'll look for a how-to
> on modifying a Dapper package for use in Breezy.
Ok, I'll try with a very quick guide:
0) install build-essential, pbuilder (you'll need to set this up to use breezy
sources, but you seem to have already done this :). Packages you might also
need are debhelper, cdbs, devscripts and fakeroot.
1) get the (dapper) sourcepackage.
Option a) You can do this either with packages.ubuntu.com/pygmy -> dapper. At
the bottom, there are three links (for native packages it would be two), that
you need to download: the .dsc-file, the .orig.tar.gz and the .diff.gz. Run
dpkg-source -x *dsc to extract the sourcepackage.
Option b) The other way to do it, is to put
"deb-src http://archive.ubuntu.com/ubuntu/ dapper universe" into
your /etc/apt/sources.list and then "apt-get source pygmy". You will end up
with the sourcepackage downloaded and already extracted (the .dsc,
the .orig.tar.gz and the .diff.gz is there, as well as a directory with the
extracted source-package which is named pygmy-<upstreamversion>).
2) Go into the top-src directory (pygmy-<upstreamversion>) and run dch -i.
Thus you'll create a new entry in the changelog. Change the
distribution-field (dapper) to breezy. You'll certainly also want to change
the version to a lower version than the dapper package. This allows you to
upgrade to the "real" dapper package, once you dist-upgrade to dapper. An
possible version number would be 0.47-1homemade1.
3) You'll need to adjust the build-depends to match versions that are in
breezy. Edit debian/control, where it says build-depends. For pygmy you'll
only need to change the version of debhelper (which says >= 5.0.0) to >=
4.0.0. see (Annotation B).
4) Rebuild the source-package with "dpkg-buildpackage -rfakeroot -S -sa -us
-uc". Thus you will get a new .dsc, .diff.gz (and now one .changes as well).
5) building the binary package
Option a) (recommended) use pbuilder to build the binary package: "sudo
pbuilder build pygmy_0.47-1homemade1.dsc". If all goes well, you'll have
a .deb-package in /var/cache/pbuilder/result.
Option b) (w.o. pbuilder): if you have installed all build-dependencies, you
could also call "dpkg-buildpackage -rfakeroot -us -uc" in the
top-source-directory. For homemade packages this doesn't really have
drawbacks, however using pbuilder has the advantage, that you'll always use a
clean build-environment, need to have build-depends set properly and pbuilder
will recognize some other faults as well.
Option c) (in case you want to debug the build process and/or need to patch
some files): You can always call the make-targets of debian/rules in the
topsrc-dir. In fact dpkg-buildpackage does nothing more than invoking a few
of the rules in a given order. If you would call "make -f debian/rules
binary", a .deb-package should be created right above top-src-dir. Calling
these rules directly has the advantage, that if you need to patch some
sourcecode files of a packages, you won't need to recompile all files again
and again until the patch is right.
6) Publishing, once you have the .deb
Option a): easy way: just upload the .deb to your webserver, and in case you
also want to publish the source-package, upload the .dsc, .orig.tar.gz
and .diff.gz as well (the .changes is not part of the sourcepackage, and only
used if you verify the integrity of a sourcepackage, e.g. if I would upload a
source-package to ubuntu's archive...)
Option b): In a way that you can just enter a line in /etc/apt/sources.list:
You could take a look at e.g. mini-dinstall, which provides a way to build
the needed files/directory structure for a repository. (I will not go into
the details, I don't know them by heart either and I guess that would be
overkill right now ;)
The versioned build-dependency debhelper is a bit special, since it is coupled
together with debian/compat. I.e. if you set debian/compat to 5, you'll need
debhelper (>= 5.0.0) and likewise reducing the needed debhelper version to
(>= 4.0.0) you should adjust debian/compat to 4. I don't know the exact
difference between these versions (you could look at debhelper's changelog
for details), but afaik you have a very high chance that it'll work with
compat level 4 as well.
Phew... well maybe it's not a "quick" guide ;)
> OK, good to know. But once you have a package built and ready, how do
> you use it on your stable installation? (I'm assuming you don't run
> Dapper for day-to-day use.)
Actually I've been running dapper for quite some time now, and currently, I
consider it quite stable... (at the *beginning* of the release cycle, the
development version however usually is far from stable ;)
> Would you backport it yourself?
Yes, probably. If it's a package that many ppl. would enjoy having, it might
also be worth to report to the backporters team... However afaik, policy is
that only packages can get backported, if no changes would need to be made.
> Yes, I saw most of these pages, but they seem to have conflicting
> information or different methods and styles, etc. After reading and
> rereading them, I certainly didn't feel confident that I understood
> very much. It's my plan to create a howto based on what I learn, so I
> guess I'll just start collecting notes. :)
That's great news... you might also want to check with the work the
ubuntu-doc-team does or join forces with them. afaik they also work on a
packaging guide. (irc-channel is #ubuntu-doc, they have a mailing list as
More information about the Ubuntu-motu