search

machinekit / machinekit-hal

Universal framework for machine control based on Hardware Abstraction Layer principle
https://www.machinekit.io
Other
109 stars 63 forks source link

Debian (and other) packaging #353

Open cerna opened 3 years ago

cerna commented 3 years ago

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 commented 3 years ago

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

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.