On 02/11/14 18:42, Andreas Barth wrote: > (I however also don't think that this is pretty bad, but of course it > is a FHS violation, and should be fixed.)
For Multi-Arch: foreign or non-Multi-Arch packages, I don't personally think this should be considered priority > normal, or (unless it's utterly trivial) fixed in jessie. > * Steve Langasek (vor...@debian.org) [141102 19:39]: >> This is /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service > > In this case I tend to say that the bug is in dbus because we should > be able to have the possibility to have per-arch services files. And > after that is fixed, systemd-shim should be adapted of course. The obvious question with per-architecture is, whose architecture? On a general multi-arch system, the architecture of /usr/bin/dbus-daemon (from dbus_*.deb, Multi-Arch: Foreign) is essentially arbitrary. I would not be keen on searching [/usr]/lib/MULTIARCH-TUPLE/dbus-1/..., because it doesn't seem to be a great idea to treat one architecture specially (namely the one for which dbus-daemon happens to be installed). D-Bus system services are basically analogous to executables in $PATH: they're looked up by an author-chosen name (a D-Bus service name rather than the executable's filename, but the principle is the same) in a search path with a well-defined order. D-Bus *session* services additionally have the historical mis-design that two implementations of the same session service name don't necessarily have either file conflicts or predictable ordering, because the .service file's name is not required to match the service name. I've contributed https://lintian.debian.org/tags/dbus-session-service-wrong-name.html in an attempt to reduce/avoid that post-jessie. My recommendation would be for packages to install their D-Bus services' executables in ${libexecdir} (or ${sbindir} or ${bindir}) rather than ${libdir}, as the GNU coding standards would already suggest. That's what Telepathy has always done, for instance. Happily, for D-Bus-activated services that are not already in $PATH, the precise location of the executable is an implementation detail, so moving the executable shouldn't break anything. Alternatively, here's a structure that would already work: /usr/share/dbus-1/system-services/com.example.Foo.service: symlink to /usr/lib/dbus-1/system-services/com.example.Foo.service /usr/lib/dbus-1/system-services/com.example.Foo.service: real file, contains multi-arch path in Exec line Alternatively^2, I'd consider a patch (preferably upstream) to insert /usr/lib/dbus-1/system-services into dbus' search path for system services, as long as it doesn't interfere with /lib/dbus-1/system-services, which is already searched (/lib in its role as the rootfs' equivalent of /usr/share). Anything using that path would need a versioned dependency on a suitable dbus to order upgrades correctly, making this undesirable for jessie at this point, IMO. Josselin Mouette wrote: > The same holds for gconf-service and gconf-defaults-service. The path > to the binary is a MultiArch one, but the package is MA: foreign > precisely for this reason. I'd say the real reason for it to be MA: foreign is "you cannot usefully have more than one copy of gconf-service installed, and regardless of which one you have, all architectures can use it". Only one executable at a time, and preferably a predictably-chosen one, can provide the org.gnome.GConf service (any other executable trying to provide the same service name is just a waste of disk space); it doesn't really matter which architecture it is, because D-Bus is an architecture-independent protocol when used correctly. Thorsten Glaser wrote: > Low-priority sounds about right, but there’s still the supposed > case of /usr/share sharing across architectures via NFS. I agree ... but does anyone actually do that in any case? The conditions for it to be valid to share /usr/share are really quite narrow (you have to have the same packages on every architecture, at the same versions, and upgrade all architectures in lockstep) and I'm having a hard time seeing how this situation could be set up without either having a complete chroot per architecture on the NFS server (in which case you might as well just serve up those chroots separately), or throwing a lot of dpkg --force at the installation/upgrade steps. (Also, the days of packaged software (/usr and friends) being larger than user data (/home, /srv) seem to have passed, and it's entirely possible to deduplicate multiple architectures' /usr/share directories with hard links or even btrfs reflinks.) Regards, S -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5456a02f.4040...@debian.org