[CMake] Packaging Best Practices for Linux

[Michael Jackson]

On May 16, 2012, at 3:41 PM, Eric Noulard wrote:

> 2012/5/16 Michael Jackson <mike.jackson at bluequartz.net>:
>> 
>> On May 16, 2012, at 1:50 PM, Andreas Pakulat wrote:
>> Andreas,
>>   Thanks for the ideas. I use bundleUtilities for OS X but not for Linux. I should adapt my code to also include Linux. One of the issues I have is that I have an HDF5 and Qwt "external" libraries that I compiled myself that I need to include.
> 
> I'm not a BundleUtilities user either but as soon as your
> BundleUtilities works on Linux you'll get
> any archive generator (TGZ, TBZ2, TZ, ZIP, ...) working as well.
> 
>> Maybe I should just install the version that "ships" with my linux Distro and then make that a requirement to compile my code? Is that what is typically done on Linux? Are there examples on the Wiki or anywhere else that shows how to setup everything needed for a .deb or .rpm?
> 
> My experience as a Linux user is that
>  1) Verify the official distro repository in order to check whether
> if the software
>  2) If 1) fails or the version is not the one I want I go to software homepage
>      and try to find out a binary package for my particular distro.
>  3) 2) does fail pretty often because the variety of linux
> distribution is huge so that
>      pre-compiled binaries may not fits my needs.
> 
> My experience as a Linux developer:
>   1) Make my software build with CMake and provide a working CPack setup
>       so that it's easy to
>             compile from source and build RPM or DEB from source at no cost
> 
>   2) Help any volunteering distro packager with my software packaging
> 
>   3) Apply to become "packager" myself in order to push my software
>       in official repo.
> 
> AFAIK in Debian the number of package (30000+) is far bigger than
> the number of Debian Developer and Debian maintainer
> http://www.debian.org/devel/people.
> So that trying to become a debian developer/maintainer "just" to have
> your software put in officiel does not seem the "debian way to go".
> 
> Now concerning how to include appropriate "binary" dependency in your
> custom build RPM or DEB
> is usually easy because RPM or DEB tools do that for you by inspecting
> the binary executables
> and libraries you did built and are wanting to package,
> 
> With your software on Linux try:
> 
> cpack -G RPM
> then
> rpm -qpR /the/generated/software.rpm
> and you'll see the dependencies discovered by rpm itself (called by
> CPack RPM) included in the generated RPM.
> 
> You may achieve the same feature with CPack DEB by
> set(CPACK_DEBIAN_PACKAGE_SHLIBDEPS ON)
> which triggers the dependency discovery using 'dpkg-shlibdeps' tool.
> 
> All that said the generated binary package will **only** work on the
> same (or almost)
> Linux distribution on which the package was built.
> e.g. If you build ian RPM on Fedora 11 it won't probably work on Fedora 15
> nor will a DEB package built on squeeze work on Ubuntu Oneiric etc...
> 
> That's why I consider the main task to be to make it easy to build RPM or DEB
> ** from source ** i.e.:
> 
> tar zxvf software.tgz
> mkdir build
> cd build
> cmake ../software
> cpack -G RPM
> 
> should work out the box.
> 
> This **cannot replace** an official distribution packaging but it can
> certainly make you Linux user happier
> that handling custom install not using the native packaging tool.
> 
> 
> -- 
> Erk
> Le gouvernement représentatif n'est pas la démocratie --
> http://www.le-message.org

That was VERY informative. This is what I was afraid of. With Windows and OS X even though there are 3 or 4 versions if you build for the earliest one (XP or 10.5) the binary has a really good chance of still running on the latest (Win7 or Lion). With Linux and so many distributions I don't have time to create that many different virtual machines to compile on each and every one. I am a single developer. I think I am going to go the source route and make sure that my software just compiles with the standard packages from each of the distros (Qt 4, HDF5 1.8, Boost and Qwt). The only issue might be Qwt as I still use Version 5 and I think there is a newer version out that I doubt I am compatible with. All else fails I have my own repo for Qwt that is public for anyone to pull from. 
   I very much want to support Linux in the best way possible. I was hoping for some thing easier but I guess this is just the way it is.

Thanks all for the help.
Mike Jackson.