I have a package that will be updated soon but I know that some of the users will prefer using the old one. That's why I used an update-alternatives routine in the package. The problem is also that the newer package depends on a newer unit files.

To sum up,

dpkg -L mypackage-1.0
dpkg -L mypackage-service-1.0

Upon install dpkg -i mypackage-1.0 will provide a single alternative to mypackage and dpkg -i myservice-service-1.0 to myservice-service

These are interdependent.

dpkg -L mypackage-2.0
dpkg -L mypackage-service-2.0

Upon install dpkg -i mypackage-2.0 will provide a new alternative (/lib/systemd/system/mypackage.service -> /etc/alternatives/mypackage.service) to mypackage and dpkg -i myservice-service-2.0 to mypackage-service

The idea behind is to allow easy yet explicit switching between versions with update-alternatives --config mypackage and update-alternatives --config mypackage-service

The first part works well but the second part turned out to be an issue. It seems like I cannot use symlinks to unit files (exactly what update-alternatives --install does).

I use systemctl 215 on Debian Jessie.

I suppose the whole thing could be laid out differently from scratch.

  • 1
    Are the two units different in ways other than the command they start? Couldn’t you ship one unit which uses the alternative for the binary? – Stephen Kitt Mar 17 '17 at 9:32
  • Sorry, as the Issue you linked to notes, this issue was fixed in a newer version of systemd. – Mark Stosberg Mar 17 '17 at 13:56

Until you can upgrade to a newer version of systemd where the issue is resolved, you'll have to use another mechanism besides update-alternatives to copy and move files instead of symlink them, as the behavior of systemd can`t be changed with the current version.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.