5

I don't even know if it's possible. If I need to create separated packages, please explain why.

Thomas Ward
  • 74,764
Wouter Dorgelo
  • 153
  • 1
    I asked this very same question to the Ubuntu MOTUs a while back, and my answer below is similar to the explanation they gave me. Since then, i've been packaging stuff for various projects (and backports) actively, with their guidance and knowledge. – Thomas Ward Dec 31 '11 at 00:09
  • additional comment In short, you cannot create a single .deb file that will always work in various Ubuntu versions. This is because of various libraries and versions, as I detail in my answer below. The long explanations exist within my answer below, as well as comparison examples so you can see why building packages separately for each version of Ubuntu is preferred. – Thomas Ward Dec 31 '11 at 00:21

1 Answers1

6

You will need to create separate packages. This is because of the potential of different library versions being required in various versions of Ubuntu.

As well, when you build the packages into the binaries, it will be building only for the libraries available within that version of Ubuntu.

Subsequently, this is why in debian/changelog you are only allowed to specify one version of Ubuntu at a time on the version line (for example: rkhunter (1.3.8-7~natty1~ppa1) natty; urgency=low - note the natty part changes to maverick, lucid, oneiric, hardy, etc.)

Take a look at the files in my rkhunter backports PPA: https://launchpad.net/~trekcaptainusa-tw/+archive/rkhunter Feel free to see what the changelog entries show, and how I named the package version numbers (you can omit the ~ppa# part at the end, but you should append the version of ubuntu to the package names if you're building for more than one version of Ubuntu, and then build each separately).

EDIT
To better see what I mean, I urge you to compare the actual debian/control files, and the debian/changelog files for the version of rkhunter in my PPA (for Lucid), and compare that to the source version in Oneiric's repos right now, you'll notice the change(s) that had to be done in order to get it to build in Lucid (such changes are common, so when building for Natty, for instance, you'll be specifying newer package versions than in Lucid or Maverick or others. The same is said for building for Oneiric, and backporting to Natty, you sometimes have to specify different versions of build dependencies, among other things, for the older version(s) of Ubuntu)

Thomas Ward
  • 74,764
  • 2
    @Mr.Pallazzo You're very welcome. Feel free to bug me with any questions you might have, my ubuntu.com email address is listed on my launchpad profile (if you login to launchpad), and you can find me in the Ubuntu IRC channels if you need any specific help (nick: Resistance, IRC network: irc.freenode.net) I also recommend the channels #ubuntu-packaging and #ubuntu-motu on irc.freenode.net if you need any additional assitance :) – Thomas Ward Dec 31 '11 at 00:41
  • 1
    You don't necessarily have to create separate packages. As long as the libraries you used in lucid are still available in latter versions, the package will install on them just fine. – psusi Dec 31 '11 at 17:39
  • @psusi that is true, but in some cases, a program needs a specific version of a library that only exists in a prior version, which is generally why people create separate package versions for each distro. – Thomas Ward Jan 01 '12 at 01:13
  • @ThomasWard, library authors and packagers work hard to make sure that does not happen. If a newer version of a library is not backward compatible, then the package name is changed so that both versions can be installed at the same time. This is referred to as an ABI breakage/bump. – psusi Jan 01 '12 at 19:20
  • @psusi rather than arguing about this, perhaps we can agree that while my method isn't always required, it does indeed prevent issues with such things as you state? – Thomas Ward Jan 02 '12 at 00:45
  • @ThomasWard, I would say that back porting a package to a previous release often, but not always, has the kind of trouble you are talking about, but installing a package that already was built for the old release on the new release almost always works just fine. – psusi Jan 03 '12 at 00:34