[Tts-project] Bug#1084827: speech-dispatcher: systemd .service file using Alias= and not symlink

[Michael Biebl]

Am 29.10.24 um 16:52 schrieb Michael Biebl:
> Am 28.10.24 um 23:41 schrieb Samuel Thibault:
>> Hello,
>>
>> Michael Biebl, le ven. 18 oct. 2024 17:55:00 +0200, a ecrit:
>>> Am 18.10.24 um 17:01 schrieb Michael Biebl:
>>>> On Wed, 09 Oct 2024 10:44:59 +0200 Laurent Bigonville 
>>>> <bigon at debian.org>
>>>> wrote:
>>>>> Package: speech-dispatcher
>>>>> Version: 0.11.4-2
>>>>> Severity: serious
>>>>> Tags: sid trixie
>>>>>
>>>>> Hello,
>>>>>
>>>>> The systemd .service file using Alias= and not symlink but as 
>>>>> service is
>>>>> not enabled, the symlink is not created.
>>>>>
>>>>> That means that the LSB script and the systemd service are not linked
>>>>> together.
>>>>
>>>> Correct, such aliasing symlinks to align sysv and systemd names should
>>>> be shipped as static symlinks in the package and not be created
>>>> dynamically.
>>>>
>>>>> Best is to drop the Alias= statement of the service and create a 
>>>>> symlink
>>>>> next to it (speech-dispatcher.service -> speech-dispatcherd.service)
>>>> In addition to that, any existing, dynamically created symlink in /etc
>>>> should be removed on upgrades, i.e.
>>>> /etc/systemd/system/speech-dispatcher.service
>>>
>>> I've uploaded the attached patch to DELAYED/14.
>>
>> Thanks for having taken a look.
>>
>> I wonder if the simplest wouldn't be to just rename the
>> (debian-specific) init script into debian/speech-dispatcherd.init, to
>> make the upstream-provided service file, do you see any downside to it?
> 
> I would consider that the cleanest solution, yes. Not necessarily the 
> simplest one though, since you need to consider that the user has 
> existing symlinks in /etc/rc?.d/ and /etc/init.d/<foo> being a conffile, 
> which makes it a bit harder to transfer over the state / clean up 
> existing state.
> 
> You probably also need to name your file debian/speech- 
> dispatcher.speech-dispatcherd.init and then add an override for 
> dh_installinit using the "--name" flag.
> 

I'm not quite sure if you wanted me to cancel the NMU for the 
alternative solution you proposed. If that is the case, please let me know.

(afaics, the alternative solution would not be complicated by my 
proposed NMU, so could be done as a follow-up)

Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/tts-project/attachments/20241029/0a65c3bf/attachment-0001.sig>