Jarle Aase wrote: > I'm about to make some .deb packages. Some will hopefully be accepted as > official packages, while others will be built for my own convenience (to > ease installation and upgrades on Debian servers I maintain). > > The packages includes shared C++ libraries, binaries, databases (MySQL) > and some Java programs. > > I have set up a machine with Debian "unstable" to work on the packages I > hope to get into the Debian distribution. I will however need all of the > packages in a "stable" repository (for my own use) and some even > backported to "Woody". > > How is the best way to maintain debianized packages that are bulit for > several Debian releases? Should I use the approach described in "Debian > New Maintainer's Guide", or some other tols like Yada? For your own purposes I would just maintain the packages on the oldest of the tracks that you need to support. That is, if sarge is the oldest that you need to support then just use a sarge build for your own use on sarge, etch, and sid. Because the system is backward compatible you can run programs compiled on the older system on the newer system. You don't need to compile your program for your own use against every release. If your oldest system that you need is woody then compile on woody and run on sarge, etch, and sid. The pbuilder package is useful to set up a chroot and build against woody on sarge and other combinations. If this is a package that you are trying to get sponsored or otherwise into Debian then it should be built against the current sid at the time of upload. This is because policy changes will dictate certain behaviorss such as the previous transition from /usr/doc to /usr/share/doc and things like that. Also it links against the current libraries and avoids dependencies against the older libraries so that they may be retired in future releases. Maintaining your own "backport" package to woody while trying to put that same package into sid can mean confusion with the package version number. If you use the same version number for both then the md5sums for the resulting official debian package in the depot will be different than the one in your backport. This can confuse both apt and yourself. In that case I would give the version to be uploaded to Debian the real version number and give your backport a backport number. That is, decrement the release number by one, append a unique identifier to denote that this is your personal backport, add a revision. For example 1.1-1 becomes 1.1-0.jarle.1. Then your machine will naturally upgrade to the official package when an upgrade is presented to it. As for maintaining your own apt depot look into using debarchiver. It works quite well for maintaining a small depot. See also mini-dinstall for another alternative. These both automate the running of apt-ftparchive to build a depot automatically. For easy uploading into your archive see dupload or dput, depending on whether you prefer perl or python respectively. Bob
Attachment:
signature.asc
Description: Digital signature