Our dh doesn't seem to understand "${env:" in *.install, so using the same approach as Debian doesn't seem to work. It always treats "${env:..." as a literal path. And yes I did remember to export the variable from debian/rules.
Just hard coding the service file paths to /usr would probably work for Launchpad builds, but is not something I'm willing to do right now since the path change hasn't graduated from proposed yet and I can't test it locally. I'm only willing to upload changes I have tested locally so it can wait till systemd has migrated... In the meantime, can anyone tell me why "${env:..." isn't understood? Is it the compatibility level?
Turns out it's not as simple as the above comments suggest.
> https:/ /salsa. debian. org/systemd- team/systemd/ -/commit/ ee83b5721 /salsa. debian. org/DebianOnMob ile-team/ modemmanager/ -/commit/ 367180c3
> https:/
udev changes are not relevant to the failures in https:/ /launchpad. net/ubuntu/ +source/ bluez/5. 71-0ubuntu1 AFAICT
> https:/ /salsa. debian. org/bluetooth- team/bluez/ -/commit/ f4d76255cdfa
Our dh doesn't seem to understand "${env:" in *.install, so using the same approach as Debian doesn't seem to work. It always treats "${env:..." as a literal path. And yes I did remember to export the variable from debian/rules.
Just hard coding the service file paths to /usr would probably work for Launchpad builds, but is not something I'm willing to do right now since the path change hasn't graduated from proposed yet and I can't test it locally. I'm only willing to upload changes I have tested locally so it can wait till systemd has migrated... In the meantime, can anyone tell me why "${env:..." isn't understood? Is it the compatibility level?