HOWTO: making a package which compiles fine on slink and potato
A modest HOWTO, which seems to work for me. Comments wlecome, you can find the
latest version on <http://www.debian.org/~bortz/slink2potato/>.
The slink2potato HOWTO for package maintainers
The aim
The purpose of this small documentation is to explain how to get both
a "slink" (currently Debian stable) and a "potato" (currently Debian
unstable) version of your packages. If you follow this documentation,
you'll have the two versions with the same source.
Why keeping two versions? Because many people use Debian for actual
work: they do not _apt-get upgrade_ every morning, and they will use
"slink" even after "potato" has been officially blessed as stable. If
you manage only packages for the current unstable version of Debian,
"slink" people will not be able to install the latest upstream
version, which they may want.
Note that I do not suggest you keep the two versions on your own
server: you can also just make a source which will compile both on
"slink" and "potato". (Most "potato" packages do not do the right
thing when compiled on "slink", becuse of too many hardcoded
assumptions.) You will still be "slink-friendly" and will help to show
that Debian maintainers are faithful to the fourth item of the
[1]social contract "Our Priorities are Our Users and Free Software ".
It is assumed that you use debhelper.
_________________________________________________________________
FHS and FSSTND
The most important difference between "slink" and "potato", in respect
to our goal, is the switch from the old FSSTND to the [2]File system
Hierarchy Standard (FHS). It typically prevents careless installation
of a binary package from "potato" on a "slink" machine and it even
breaks many package sources.
Ideally, _debhelper_ should do everything for you. In practice, many
debian/rules have hardcoded pathnames for various reasons. The best
thing is to try to suppress them. If you cannot do it easily, then at
least parametrize your debian/rules. To do that, first ask _debhelper_
on which version you run:
ifeq ("$(shell dh_testversion 2.0.40 && echo potato)", "potato")
DOC = usr/share/doc
MAN = usr/share/man
LIB = usr/share/lib
else
DOC = usr/doc
MAN = usr/man
LIB = usr/lib
endif
Then, you can use these new variables in debian/rules:
./configure --datadir=/$(LIB)
...
# Support for the old name, xt
ln -sf xtraceroute debian/tmp/$(LIB)/xt
Congratulations! You know have a "slink-friendly" package (as long as
all the filenames in the program are handled by _autoconf_ or similar
means).
_________________________________________________________________
Numbering your versions
When you build the two packages yourself, pay attention to the version
numbering: you typically want the "slink" version to have a lower
number, so that future upgrades will do the right thing and install
the "potato" version. To do so, I use a numbering scheme which is the
one used in [3]NMUs: if my "potato" package is 1.2-5, I call the
"slink" package 1.2-4.999. That way, it has an inferior number, and
the packages can follow their normal life, being upgraded, without
fearing a collision.
Your debian/changelog could look that way:
foobar (0.8.14-1) unstable; urgency=low
* New upstream release.
* Frobnicates more. Closes #32199.
-- Stephane Bortzmeyer <bortzmeyer@debian.org> Thu, 14 Oct 1999 11:08:35
+0200
foobar (0.8.14-0.999) stable; urgency=low
* "slink" (stable) version of the above.
-- Stephane Bortzmeyer <bortzmeyer@debian.org> Thu, 14 Oct 1999 11:08:35
+0200
In that case, for compiling on the "slink" machine, _be sure you
removed the lines_ about the "potato" version first.
You typically upload on master only the "potato" version and leaves
the "slink" one on a local server, as explained in the next section.
_________________________________________________________________
Keeping your archives
You can upload the "potato" package with dupload or a similar tool.
For the "slink" version, you can let users get it with apt, which is
typically the simplest thing for them.
In order for them to do so, you have to find a server somewhere (it
can be your account on [4]www.debian.org) and to create Packages file.
This is done by _dpkg-scanpackages_, in dpkg-dev. Here is an example:
EXT=dists/stable/binary-i386 \
dpkg-scanpackages $(EXT) /dev/null "" | \
gzip -9 -c > $(EXT)/Packages.gz
References
1. http://www.debian.org/social_contract
2. http://www.pathname.com/fhs/
3. http://www.debian.org/doc/packaging-manuals/developers-reference/ch-nmu.h
tml#s-nmu-version
4. http://www.debian.org/doc/packaging-manuals/developers-reference/ch-serve
rs.html#s-servers-www
Reply to: