I've sent a summary of discussion about this upstream and will wait for
their response, and there's something I still want to ask for clarification.
On 1/9/25 12:55, Michael Biebl wrote:
Am 08.01.25 um 19:44 schrieb Chris Knadle:
Hello, Michael.
I'm emailing again because I've tried again to follow the suggestions
that were made for this bug, and it is not working.
On 11/22/24 06:09, Michael Biebl wrote:
Again, I don't understand why you try to fiddle with debian/rules
and variables in .install files (don't do that)
The directive here is to avoid using variables in the .install file.
You install systemd-dev (including systemd.pc), the build system
picks up the paths from systemd.pc via pkgconf and installs the
files into the correct paths. All you need to do in .install is
reference the now correct paths.
Then the directive here is to reference a "correct path" in the
.install file, which presumably is in a variable. (?) Or, whatever
the "correct path" is meant to mean, I don't know what that is and
cannot interpret it.
No, all you are supposed to do in your .install files is to use the
correct paths
/usr/lib/systemd/system/foo.service
/usr/lib/sysusers.d/foo.conf
/usr/lib/tmpfile.d/foo.conf
I think I finally have an answer to "What does this actually solve?"
If the destination of these configuration files is being manually
specified in mumble-server.install, then what the build dependency on
systemd-dev and pkgconf is doing is tracking where the /upstream source/
is building those files to and moving them to the specified destination.
The work this theoretically saves is tracking if the upstream source
moves files related to systemd. Such as 1.5.517 installing
/etc/sysconfig.d/mumble-server.conf and 1.5.735 installing it to
/etc/sysusers.d/mumble-server.conf. So this doesn't do anything for a
situation where the systemd file destinations need to change.
So is that correct? I'm explicitly asking because nowhere in the
discussion about this bug was this clear to me.
-- Chris
Chris Knadle
chris.kna...@coredump.us
