Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debian (and other) packaging #353

Open
cerna opened this issue May 24, 2021 · 1 comment
Open

Debian (and other) packaging #353

cerna opened this issue May 24, 2021 · 1 comment

Comments

@cerna
Copy link
Contributor

cerna commented May 24, 2021

This is and should be part of tackling of issue #200, of which the progress can be followe in #349.

Currently, the Debian packaging (pretty much the only active packaging, if we don't consider the stale attempts at Python packaging relevant) produces the machinekit-hal source package and machinekit-hal, machinekit-hal-dev, machinekit-hal-posix and machinekit-hal-rt-preempt binary packages. This is problematic because it does not follow Debian's rules for distribution of software and thus the downstream cannot use for example MultiArch when cross-compiling an application based on Machinekit-HAL framework - simply because the libraries and executables are bundled together.

Machinekit-HAL binary packages also do not currently follow the stipulated filesystem and libraries are put into the /usr/lib directly without the platform specific triplet, there is a /usr/libexec directory for internal executables, but Debian based distributions expect you to put these in /usr/lib/${DEB_HOST_MULTIARCH}. The Python parts are not packages as Python3-* binary packages (this is probably not a must.)

In the view of depicted, I have been thinking how to redo the packaging for the new build system. So far what I have been able to come up with is to isolate every and all Python package to its own Python specific packaging process and generate a wheel for it, this way you can install it into any virtual environment. To install it to the basic Debian system-wide installation, use a tool like Wheel2Deb to generate the .deb from wheel. Then create binary package with the basic executables to run Machinekit-HAL configuration, binary package with basic libraries to run Machinekit-HAL configuration and binary package with devel files for these libraries. Everything else would get it own package, i.e. every HAL module would have its own package. This should go nicely with ability to create as tight installation system as possible.

Then there would be a wrapper package (something like the current machinekit-hal-rt-preempt) to get the full Machinekit-HAL installation like one would get now.

My hopes are that this structure could be portable to other distribution's packaging.

@cerna
Copy link
Contributor Author

cerna commented Jul 5, 2021

Starting to realize this idea, I came up to a problem that the sheer numbers represent:

  • There are over two hundred managed HAL components (and2v2, limit3v2 etc)
  • There are almost 30 managed HAL drivers
  • There are tens of unmanaged modules (so called userspace components)
  • There are over ten shared libraries

To package all of that into separate packages, well, that would be a lot of packages. I still think this is an interesting idea and should be considered in one way or another. But let's just say - more down the line.

So I come up with following Debian packages:

  1. machinekit-hal: Executables needed for Machinekit-HAL run
  2. machinekit-hal-dev: Executables needed for building on top of Machinekit-HAL base
  3. libmachinekit-hal: Libraries of Machinekit-HAL (for Multi-Arch, maybe added -base to name)
  4. libmachinekit-hal-dev: Headers and sonames for libraries of Machinekit-HAL (maybe added -base-dev to name)
  5. modmachinekit-hal-components: Managed HAL components of Machinekit-HAL
  6. modmachinekit-hal-drivers: Managed HAL drivers of Machinekit-HAL
  7. modmachinekit-hal-unmanaged-modules: Unmanaged HAL modules of Machinekit-HAL
  8. python3-machinekit-hal: Everything Python of Machinekit-HAL

This way, separating something into its own package would be relatively easy.

The Python stuff will be packaged per module into its own wheel and uploaded to a registry. I think it is more important to have wheels than Debian packages, as everybody is using virtual environments anyway for development and complex deployment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant