Re: Arch-dependent files in /usr/share
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 (vorlon@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
Reply to: