Repackaging a Debian package for use with Breezy

[Stefan Potyra]

Hi again,

(moving to ubuntu-motu list, as I think this is a better place for this 
topic).

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 ;)

Annotation A:
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 
well).

Cheers,
	Stefan.