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.
Best Answer
Until you can upgrade to a newer version of
systemdwhere the issue is resolved, you'll have to use another mechanism besidesupdate-alternativesto copy and move files instead ofsymlinkthem, as the behavior ofsystemdcan`t be changed with the current version.