On Mon, 09 May 2016 at 14:32:44 +1200, Daniel Reurich wrote: > Can't we get the test-suite to make the needed homedir if it doesn't > exist before hand. In the case of Devuan with jenkins this is all done > in a scratch-space anyway so no big deal. I'm assuming the same goes > for Debians sbuild/builds
No, we can't. sbuild deliberately uses a nonexistent home because, by policy, packages should not write to the home directory during build. For most packages, this is fine, because setting $HOME redirects accesses to that directory. However, D-Bus' use of the home directory is as an access control mechanism: it checks for ability to write to the home directory, as a way to prove that a connecting user does indeed have the claimed uid. This deliberately ignores the $HOME environment variable and uses the uid's "official" home directory according to /etc/passwd[1], because for the system bus it has to work for uids that do not match the uid of the dbus-daemon. In practice we don't use that access control mechanism on Debian, because Linux, kFreeBSD and Hurd all support AF_UNIX credentials passing (EXTERNAL authentication) which is just better, and we force the standard dbus-daemon instances to use AF_UNIX and EXTERNAL as a security hardening measure. However, it's part of upstream test coverage, because it is needed on some platforms (Windows, possibly some bad Unix implementations) and in some (inadvisable) configurations (sharing a bus over TCP on a trusted network in conjunction with NFS-shared $HOME). In principle this could be addressed by LD_PRELOADing a module that fakes the result of getpwent(), by special-casing the home directory lookup to treat $HOME as getuid()'s home directory even if it differs from /etc/passwd, or by automatically skipping the relevant test-cases if the "official" home directory doesn't exist or if $HOME doesn't match. So far I haven't had the time to do any of those, or even decide which one is best, but I'd be happy to review a patch. The LD_PRELOAD option is non-portable and would have to be Debian-specific (glibc-specific, really); the $HOME special-case or automatic skip should go upstream. If Devuan is already modifying the dbus package, and Devuan does not share Debian's policy about home directory access and is building as a user who does have an "official" home directory, then there is nothing to stop Devuan from modifying debian/rules to run the tests. I still don't understand why Devuan is modifying dbus at all; the Debian package works fine on a system not booted using systemd. Yes, it links to libsystemd; it also links to libapparmor and libselinux, and there's no way those two can both be useful during the same boot! Library dependencies that are useful on other people's machines but not yours are the price you pay for the advantages of running a binary distribution like Debian/Fedora/SuSE, not a source distribution like Gentoo or BSD ports. Even if Devuan wants to avoid libsystemd for purely political reasons, a stub implementation of libsystemd that responds to all API calls as though not using systemd, similar to <https://anonscm.debian.org/cgit/users/md/libsystemd-dummy.git>, seems a far better technical solution than patching every package that has some sort of systemd integration. S [1] technically nsswitch