IRTK "info" executable can replace / shadow Linux's info utility
Closed this issue · 10 comments
Dear all,
I have attempted to build a Debian package out of IRTK, with the intent to share it with my colleagues at Kings' and eventually with you guys if you are interested. I have gotten to a point where I can successfully build a DEB package containing all the IRTK binaries, but I am facing a few issues.
The biggest issue concerns the IRTK info binary whose name clashes with the default Linux's info. Regardless of your installation method, i.e. directly under /usr or in a user specified directory + override of the user's $PATH, the info utility ends up either overwritten or shadowed.
I would suggest to rename this binary to irtk_info (which is the solution I went for downstream). Please feel free to comment if you think of a better solution.
Cheers,
Ghis
Hi,
Thanks a lot for this initiative of a Debian package, that's great news!
Personnally, I am more worried by the name conflicts between ImageMagick and IRTK, such as convert, but the point is: IRTK binary names are not fit for a system install.
The fix I would suggest would mean just adding a few lines to the CMake files so that when the binary are built, they are renamed:
irtk${VERSION_NUMBER}-${binary_name}
If you look at the fsl binaries:
http://packages.ubuntu.com/precise/amd64/fsl-4.1/filelist
that's how it is done, and it does not make sense to rename all the C++ files.
Kind regards,
Kevin
Personnally, I am more worried by the name conflicts between ImageMagick and IRTK, such as convert, but the point is: IRTK binary names are not fit for a system install.
I second that, but this can be worked around.
If you look at the fsl binaries
Actually, the executables in /usr/bin are symlinks / wrappers to the original binaries stored in a private location under /usr/lib/fsl/$(FSL_VERSION)/ , which is an idea I did not think of. I believe this approach could work with IRTK too.
irtk${VERSION_NUMBER}-${binary_name}
Would you guys be happy with this solution, i.e. all binaries stored under /usr/lib/irtk/$(ITK_VERSION) and symlinks / wrappers using the FSL name convention as you suggested ?
EDIT: added versions in paths
This seems to me a clean solution.
FYI, I have just implemented the FSL trick with the IRTK packaging and it works fine. Thank you for the suggestion @kevin-keraudren .
Thanks for your efforts to provide an easy to install Debian package. This will be much appreciated not only by us but in particular external users! After all, building IRTK can be a mess at the moment...
Personally, I am not a fan of the version number in the executable name. If I write a pipeline script, I would have to make it flexible enough to replace the version by the actual installed IRTK version. Also, the resulting executable names are simply not aesthetic. A common prefix such as "irtk" to avoid name conflicts with other software, on the other hand, is pretty much the only solution to this problem I can think of. But of course there shouldn't be executables named after Unix commands in the first place. My suggestion would be to drop the version number from the symbolic links. If a system administrator were to upgrade the IRTK package, this shouldn't require all pipeline scripts that use IRTK executables to change the name of the executable they are calling. In the end, a multiple version installation is still possible simply by having these in different installation directories (i.e., /usr/lib/irtk/$irtk_version). The symbolic links in /usr/bin should point to the most recent or current default version of these binaries. If an admin was to switch to a newer version, only the symbolic links change, but all dependent executables remain unchanged.
How do you create the Debian package ? Given that we are using CMake for the build system, I would hope the Debian package is based on CPack ?
Thanks for your efforts to provide an easy to install Debian package. This will be much appreciated not only by us but in particular external users! After all, building IRTK can be a mess at the moment...
This feeling was shared by my fellow colleagues, hence my effort to provide a package.
How do you create the Debian package ? Given that we are using CMake for the build system, I would hope the Debian package is based on CPack ?
Debian just uses standard make files with additional "meta-scripts" called debhelpers, which are made aware of standard build systems like automake, cmake, scons, setuptools...Then, it's "just" a matter of putting the resulting binaries in the right place within the package.
Regarding the packaging, I went for the following option for now:
- the IRTK executables gets installed in /usr/lib/irtk$(IRTK_MAJOR_VERSION), so that their names don't clash with any other system component
- versioned symlinks are provided to /usr/bin for all executables, in the form irtk$(IRTK_MAJOR_VERSION)-$(BINARY_NAME)
- non-versioned symlinks are provided, pointing at the symlinks for the most recent version, in the form irtk-$(BINARY_NAME)
This provides maximum flexibility in the upgrade process and is not much of a problem to manage from a packaging point of view. Any objection ?
I will upload everything to the following PPA [1] once everything is tested.
Debian just uses standard make files with additional "meta-scripts" called debhelpers, which are made aware of standard build systems like automake, cmake, scons, setuptools...Then, it's "just" a matter of putting the resulting binaries in the right place within the package.
I am not familiar with the particulars, so I might miss some insights, but my point is that if you create those make files and meta-scripts per hand, it could require maintenance of these files for later versions of IRTK and hence knowledge of the particular structure of Debian packages. If I am understanding it right, in the CMake ecosystem, it would be CPack's Debian package generators task to create those make files and meta-scripts from the information provided in the CMakeLists.txt files of IRTK (which at the moment is not the case, i.e., would require some CMake coding/changes in IRTK). The advantage being that from the same CMakeLists.txt, CPack will be able to create also other flavors of binary packages, e.g., for RedHat Linux, OS X, or MS Windows, without an additional extra effort.
For the moment, a specific hand-crafted Debian package will do perfectly. In the long run, I would prefer a CPack based solution that the developers of IRTK will have to take care of. I was just interested if you might have gone this road already and might be able to provide us with a suitable patch of the existing CMakeLists.txt files.
The initial debianization of the source tree, i.e. adding the relevant Debian metadata on top of the pristine source tree is the most painful bit (which is what I am doing now). Then, it is just a matter of fetching the tag when a new release is made and refreshing the package creation. The degree of maintenance downstream at the package level actually depends on how volatile upstream development (particularly its build system / installation tree) is.
CPack is also an option which I am familiar with, and both an official Debian package and an upstream CPack generated package can actually co-exist if done right. Since I am only interested in providing a package via a PPA channel, the CPack option is low in my priority.
I have made a first upload in the following PPA [1] for Ubuntu 14.04 LTS. This is still work in progress though and not all the components of IRTK are built yet. Any piece of feedback is welcome.
I am closing this issue. The solution discussed with @kevin-keraudren and @schuhschuh, i.e. using symlinks of the form irtk-$(BINARY_NAME) is the one I went for in my packaging work. Many thanks to you both.