7

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
/opt/mypackage-1.0/binary
dpkg -L mypackage-service-1.0
/opt/mypackage-1.0/mypackage.service

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
/opt/mypackage-2.0/binary
dpkg -L mypackage-service-2.0
/opt/mypackage-2.0/mypackage.service

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.

2
  • 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? Commented Mar 17, 2017 at 9:32
  • Sorry, as the Issue you linked to notes, this issue was fixed in a newer version of systemd. Commented Mar 17, 2017 at 13:56

1 Answer 1

1

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .