I.e. they take from the cargo deb metadata or fall back, which is what the README says should happen for package name but doesn't seem to. I found this because my systemd unit file named <package>.<unit>.service was not being found because it is looking using the top level package name and not the name override given in the cargo deb metadata.
However, that line of code appears to have been the same since the "initial code drop" 6 years ago, so maybe I'm missing something.
I'm inclined to think it should be:
name: deb.name.clone()
As deb.name is set to the cargo deb metadata name value, or if not present is set to the main package name and so is always set.
I can push a one line PR for this if you concur? I'm wondering however if even if this functionality is not as documented (assuming I'm not confused), are there users of cargo deb out there whose builds depend on the current functionality and so we cannot change it...
The README says:
Yet in the code I see:
Unlike the lines around it which look like:
I.e. they take from the cargo deb metadata or fall back, which is what the README says should happen for package name but doesn't seem to. I found this because my systemd unit file named
<package>.<unit>.service
was not being found because it is looking using the top level package name and not thename
override given in the cargo deb metadata.However, that line of code appears to have been the same since the "initial code drop" 6 years ago, so maybe I'm missing something.
I'm inclined to think it should be:
As
deb.name
is set to the cargo deb metadataname
value, or if not present is set to the main package name and so is always set.I can push a one line PR for this if you concur? I'm wondering however if even if this functionality is not as documented (assuming I'm not confused), are there users of
cargo deb
out there whose builds depend on the current functionality and so we cannot change it...