Eu tenho um pacote que será atualizado em breve, mas sei que alguns usuários preferirão usar o antigo. É por isso que usei uma rotina update-alternatives no pacote. O problema também é que o pacote mais novo depende de arquivos unit mais recentes.
Para resumir,
dpkg -L mypackage-1.0
/opt/mypackage-1.0/binary
dpkg -L mypackage-service-1.0
/opt/mypackage-1.0/mypackage.service
Após a instalação, o dpkg -i mypackage-1.0 fornecerá uma única alternativa para mypackage e dpkg -i myservice-service-1.0 para myservice-service
Estes são interdependentes.
dpkg -L mypackage-2.0
/opt/mypackage-2.0/binary
dpkg -L mypackage-service-2.0
/opt/mypackage-2.0/mypackage.service
Após a instalação dpkg -i mypackage-2.0 fornecerá uma nova alternativa ( /lib/systemd/system/mypackage.service -> /etc/alternatives/mypackage.service ) para mypackage e dpkg -i myservice-service-2.0 para mypackage-service
A ideia por trás é permitir a alternância fácil e explícita entre as versões com update-alternatives --config mypackage e update-alternatives --config mypackage-service
A primeira parte funciona bem, mas a segunda parte acabou sendo um problema.
Ele parece como eu não posso usar links simbólicos para arquivos unitários (exatamente o que o update-alternatives --install faz).
Eu uso systemctl 215 no Debian Jessie .
Suponho que a coisa toda poderia ser diferente do zero.
Até que você possa atualizar para uma versão mais recente de systemd onde o problema foi resolvido, você terá que usar outro mecanismo além de update-alternatives para copiar e mover arquivos em vez de symlink , como o comportamento de systemd não pode ser alterado com a versão atual.