Skip to content
This repository has been archived by the owner on Oct 15, 2024. It is now read-only.

Debian/Ubuntu packaging #3558

Closed
markus2330 opened this issue Nov 14, 2020 · 2 comments · Fixed by #3583
Closed

Debian/Ubuntu packaging #3558

markus2330 opened this issue Nov 14, 2020 · 2 comments · Fixed by #3583
Assignees

Comments

@markus2330
Copy link
Contributor

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. Remove kdbproposal #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 Failing tests after installing deb package and dependency problem on Ubuntu Focal #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. bring the debian folder 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 kdb run_all does not execute external tests #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
Copy link
Member

robaerd commented Nov 15, 2020

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
Copy link
Contributor Author

Thank you so much for looking into it! 💖

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 👍

@markus2330 markus2330 mentioned this issue Nov 26, 2020
15 tasks
@robaerd robaerd mentioned this issue Dec 8, 2020
20 tasks
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants