Libelektra: Debian/Ubuntu packaging

[markus2330]

This is actually already a long outstanding issue but hopefully @robaerd can bring some new ideas&solutions.

Currently we have debian branch, which contains the introductions for Debian packaging.

Problems:

1. when a PR introduces a change of the installed files, building the debian package fails (at least when a file gets removed), e.g. #3201. Then the debian branch needs to be updated, which sometimes makes master fail (until the PR gets merged).
2. as some dependencies are debian specific, ubuntu packages are not optimal #3556 (and/or the other way round)

Ideas we had so far:

• Make a new ubuntu branch from the debian branch where the deps specific to Ubuntu are maintained. This would make the problem 1. even worse
• Merge the debian branch into master. #2353 This would fix 1. but does not bring a solution to 2.
• Stop maintaining a separate debian way of packaging and use CPack #2372 with CPack components. This might also be a solution for plenty of other formats, like RPM and would hopefully fix 1. and 2. (if and how dependencies can be described needs to be investigated, though)
• Stop maintaining our debian branch and move our package building stuff to https://openbuildservice.org. This unfortunately does not help with 1. (makes it actually worse as then the problem cannot be solved with a PR at all) and I do not know which (if any) solution they have for 2.

So cpack looks actually the most promising. @robaerd can you please investigate if:

• are there maybe better alternatives we do not know about yet?
• is it really possible to make proper modular packages (with correct deps and so on) or are these debs from the CMake maintainers point of view actually only more considered to be an archive (this was the case a few years ago)

[robaerd]

are there maybe better alternatives we do not know about yet?

I did not find any better alternative that supports modular or component based packaging. I also think CPack would be the best fit.

is it really possible to make proper modular packages (with correct deps and so on) or are these debs from the CMake maintainers point of view actually only more considered to be an archive (this was the case a few years ago)

Yes this should be possible. The component grouping depends on the package generator. CPackDeb for example would generate proper modular packages and not archives.

... (if and how dependencies can be described needs to be investigated, though)

Managing dependencies should not be a problem, since the dependencies could be declared conditionally for each component dependent on the distro with CMake.

I will try to get the old CPack configuration in scripts/cmake/ElektraPackaging.cmake running and expand it with modular packages (components).

[markus2330]

Thank you so much for looking into it! :sparkling_heart:

Managing dependencies should not be a problem

Would be amazing if they finally can handle this!

So that there is no misunderstanding of what I mean with "dependencies": dpkg-buildpackage has quite some magic to detect run-time dependencies. For example, libelektra4-python depends on "libc6 (>= 2.4), libgcc1 (>= 1:3.0), libpython3.7 (>= 3.7.0), libstdc++6 (>= 4.1.1)". We did not write this anywhere (you can check here: https://github.com/ElektraInitiative/libelektra/blob/debian/debian/control), dpkg-buildpackage figured this out by itself (it looks into the libraries that were built). Maybe we can live with a little bit more sloppy dependency management, let us see.

I will try to get the old CPack configuration in scripts/cmake/ElektraPackaging.cmake running

For me (Debian buster), cpack still works without any problem but it does not have anything in Depends: at all. Also Filename: (this might be needed to have it in a repo) and all the hashsums are missing. Most people would not consider this as proper Debian package but as an archive that has ".deb" extension.

and expand it with modular packages (components).

Perfect :+1: