views:

59

answers:

4

We have two challenges deploying our application for Ubuntu/Debian:

1. Offline installation

Many (let's say 50%) of our users will need to install offline. They will have zero internet connectivity. Thus, we need to include all possible dependencies (run time / third-party libraries, etc.) on an installation CD/DVD. It looks like perhaps APT-on-CD might be a solution here, but the documentation I read wasn't exactly clear.

2. Not-yet-supported versions of packages

Some dependencies are not yet supported by the "official" Ubuntu repositories. For example, version 4.2 of a particular library is provided in the Software Center, but my application requires version 4.4--which is a stable release, just not in the official repository packages. (The stable distribution of Debian is even further behind, still in version 3.)

  • Should I then initially create my own .deb package for these, or just install the libraries in somewhere like /usr/lib/myapp?
  • If I create my own .deb, should I give it the same (likely) name as the official package? That is, I would anticipate many (if not all) of these packages to be officially provided at some time in the future. Thus, ideally the installation procedure (in an online situation) would look first to the official repositories for the library, but be able to fall back to the CD/DVD if necessary. Is this possible, or do I just name by package something totally different and let it permanently live side-by-side?

What are the best practices for handling these installation challenges?

+1  A: 

Offline installation: have you tried apt-offine?

Debian testing and unstable are great sources for newer versions of a certain package. Debian stable doesn't get many updates - the packages are either patched. Only if upstream releases a bugfix release does it become possible for stable to get new changes.

If you want to get newer packages for a certain application, you should, ideally, download the source package and build it yourself (this doesn't require any packaging from you).

dget http://something.debian.org/path/to/source-pkg.dsc

You can either use debuild or pbuilder (pbuilder is better because it downloads the build dependencies itself and uses a clean room environment to build).

Finally, a great place to get source packages for debian packages in unstable (sid) or testing (currently also known as squeeze), the package tracking system would be a great place to find them (look on the left sidebar, you will find a link to a version of the package in unstable and testing. This links to the .dsc file. Download the whole package using dget available from the devscripts package.

http://packages.qa.debian.org/name-of-source-package
Umang
+1  A: 

Overwriting libraries with self-built newer versions is unwise, as this may break other applications on the system. The newer version may contain regressions or may be binary incompatible. If possible, consider spending the extra effort to make it work with the version supplied with the distribution. Otherwise, use a private version that will not be used by other applications. Be careful with libraries that may have security holes -- you will need to upgrade the private versions as well.

jilles
A: 

Make a static build of your application and you're done.

This is how it usually done in typical proprietary software like Skype, though the latter have both dynamic and static builds.

sanmai
Unfortunately, this is not an option for us. Some of the libraries, by LGPL license restriction, must be shared. It also makes it impossible to send out minor hotfixes, which is something we would like to keep open.
Dave
+1  A: 

1) if you have packages on a media of some sort, there should be no need to use apt, just simple dpkg -i /where/your/media/is/mounted/*.deb should be enough to install things ?

2) Alternative of shipping packages that are not yet supported by your distro but keeping your clients distro compatible with what ever software they have is to repackage those dependencies. Change the name of the package by adding a prefix to it and change the installation directory something like /opt/prefix/ instead of /usr

The compile your application with -rpath flag pointing to the location where your required libraries are provided (afaik debian rules disallow rpath usage thou) or make your application start only from a shellscript that sets a proper LD_LIBRARY_PATH before it starts your real application.

rasjani