You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
machinekit-hal: Executables needed for Machinekit-HAL run
machinekit-hal-dev: Executables needed for building on top of Machinekit-HAL base
libmachinekit-hal: Libraries of Machinekit-HAL (for Multi-Arch, maybe added -base to name)
libmachinekit-hal-dev: Headers and sonames for libraries of Machinekit-HAL (maybe added -base-dev to name)
modmachinekit-hal-components: Managed HAL components of Machinekit-HAL
modmachinekit-hal-drivers: Managed HAL drivers of Machinekit-HAL
modmachinekit-hal-unmanaged-modules: Unmanaged HAL modules of Machinekit-HAL
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.
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 andmachinekit-hal
,machinekit-hal-dev
,machinekit-hal-posix
andmachinekit-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 asPython3-*
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
fromwheel
. 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.
The text was updated successfully, but these errors were encountered: