-
Notifications
You must be signed in to change notification settings - Fork 11
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
Require specific Machinekit-HAL package version #6
Require specific Machinekit-HAL package version #6
Conversation
I'm not too nutty about being required to provide a specific MK version on the |
@zultron, LinuxCNC currently has no packaging support for Python 3 as noted in #2 (however this problem will not go away once it has it). And it presumes that all parts are compiled in one go. That is not a true when using combination of Machinekit-HAL and EMCApplication. As both can be compiled at different time and user can use time displaced versions. (He can have old version of Machinekit-HAL and current version of EMCApplication and vice versa.) Machinekit-HAL is now Python 3 only software. LinuxCNC currently allows both Python 2 and Python 3 functionality. It is done (in LinuxCNC) the special way that the Python version is decided at compile time and from there stems the problem. When one tries to compile the packages from current EMCApplication@master:
(Be aware that currently to build the packages one needs to do two changes [this change is part of this pull request]: delete the
Then try to run the compiled packages:
You will get something like this:
Which basically means that it is looking for Python 2 module of HAL, but it is not there. (Because the module is of Python 3 version.) This is the reason why I think the pinning of dependency package (in this case Machinekit-HAL) version - the same version used for building and for installing - is unavoidable. Of cource, one of the mistakes was to not raise the version number when Machinekit-HAL become exclusivelly Python 3. I am open to all and any ideas as to how solve this isue without specifying special version. I just cannot think of any other way at the moment. |
Encompass needed local patches to work around upstream development changes.
When building Debian-like packages for external HAL (Machinekit-HAL), require a specific package version of 'machinekit-hal' and 'machinekit-hal-dev' when running the configure command. Example: './debian/configure machinekit-hal=0.4.20868-1.gitca75c54aa~stretch no-docs'
79a3514
to
d91ce69
Compare
During discussion about pull request machinekit/EMCApplication#6 it became obvious that the reason why building Machinekit EMCApplication requires explicitly stating which version of Machinekit-HAL will be required is not apparent. Thus, this note was written in hopes it will shed light into the process.
After offline discussion with @cerna, we're on the same page about this. Sorry for the delay, and thanks! |
…ATURE: Add note about requiring 'machinekit-hal' package version During discussion about pull request machinekit/EMCApplication#6 it became obvious that the reason why building Machinekit EMCApplication requires explicitly stating which version of Machinekit-HAL will be required is not apparent. Thus, this note was written in hopes it will shed light into the process.
This pull request implements package locking to specific version of
machinekit-hal
packages as mentioned in issue #2. The new functionality works by requiring parameter when running thedebian/configure
bash script:It will create a
debian/control
file with specified versions:Because of the problem with package solver in standard Debian apt when running the mk-build-deps, there is need for additional package name apt-cudf, which allows using smarter dependency solver:
This simpler implementation over the more magical one - the first idea was using
dpkg
to look for installed packages ofmachinekit-hal
plusmachinekit-hal-dev
and lock to this version or download available version data from Machinekit's repository - was chosen after realization that this functionality is already part of apt and that CI (or user) should look for available versions as the address of remote repository is not known.This change is already documented in pull request machinekit/machinekit-docs#320.