On Sat, 02 May 2026 at 22:37:44 +0200, Alexandre Detiste wrote:
Having a "<something->tmpfiles.conf" filename inside /usr/lib/tmpfiles.d/
feels nonsensical (maybe that's less work with dh_install).
This is actually from upstream, not Debian-specific. Upstream has
sysusers.d(5) and tmpfiles.d(5) snippets both coming from data/ in the
source code, so they can't both be named polkit.conf (or polkitd.conf)
without moving at least one of them to a subdirectory, which would make
the build system more verbose.
polkit is the name of the upstream project (in Debian it's still
src:policykit-1, the old name, for historical reasons) so polkit.conf or
polkit-*.conf makes sense as a name. In Debian we split the source
package into multiple binary packages, so polkitd becomes its own
package, but in some other distros like Arch the whole polkit codebase
turns into one "polkit" package.
Upstream is unlikely to rename things to make more sense in Debian if it
comes at the expense of making the naming make less sense in some other
distro.
Could this be renamed to /usr/lib/tmpfiles.d/polkitd.conf ?
I currently needed a special casing in my tool cruft-ng
to handel this weirdness.
There is no API guarantee that tmpfiles.d(5) snippets' names are a
perfect match for Debian package names: polkit[-tmpfiles].conf could
equally well have been in a polkit-common package or something like
that. The only real requirement is that the names have enough
namespacing to avoid collisions between unrelated packages.
Could cruft-ng perhaps look at the package that owns the file
(dpkg -S equivalent) rather than its filename?
smcv
_______________________________________________
Pkg-utopia-maintainers mailing list
[email protected]
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-utopia-maintainers
