Re: Re: Arch-dependent files in /usr/share
Russ Allbery: I think it's worth considering whether we should just dump the Lintian checks for arch-independent files in /usr/lib, and make a corresponding change to Policy that says that packages are free to put arch-independent files there. It would as a side-effect make you better aligned with the systemd Filesystem Hierarchy Standard. (-: * http://freedesktop.org./software/systemd/man/file-hierarchy.html Static, private vendor data that is compatible with all architectures (though not necessarily architecture-independent). -- 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/545811c4.2020...@ntlworld.com
Arch-dependent files in /usr/share
I found a number of arch!=all packages shipping /usr/share files that vary with architecture in a way indicating an FHS violation. DD-list of the affect binary packages is attached, and diff between i386 and s390x is here: https://people.debian.org/~jwilk/qa/20141101-usr-share.diff Please fix your packages. :-) -- Jakub Wilk Adrian-Ken Rueegsegger k...@codelabs.ch libapq-postgresql4-dev Albin Tonnerre lu...@debian.org e17 (U) Andreas Henriksson andr...@fatal.se gconf-defaults-service (U) gconf-service (U) Andreas Metzler ametz...@debian.org autogen Andreas Tille ti...@debian.org anfo (U) libvxl1-dev (U) Andrew Ross andrewr...@users.sourceforge.net plplot-tcl Anibal Monsalve Salazar ani...@debian.org heartbeat (U) Anton Gladky gl...@debian.org gerris-mpi (U) libcoin80-dev (U) libsimage-dev (U) libsoqt4-dev (U) Antonin Kral a.k...@sh.cvut.cz aranym Arno Töll a...@debian.org apache2-dev (U) Arthur Loiret aloi...@debian.org gawk Axel Beckert a...@debian.org wml (U) Bastien Roucariès roucaries.bastien+deb...@gmail.com imagemagick-6.q16 (U) Changwoo Ryu cw...@debian.org ibus-hangul (U) Chow Loong Jin hyper...@debian.org banshee-meego (U) Christophe Prud'homme prudh...@debian.org libdolfin-dev (U) ufc (U) Cyril Brulebois k...@debian.org xserver-xorg-dev (U) Cédric Boutillier bou...@debian.org libqtruby4shared-dev (U) Daniel Baumann m...@daniel-baumann.ch lxc Daniel Kobras kob...@debian.org imagemagick-6.q16 (U) David Palacio dpala...@orbitalibre.org libqtruby4shared-dev (U) libsmokeqt4-dev (U) Debian Accessibility Team debian-accessibil...@lists.debian.org brltty Debian Apache Maintainers debian-apa...@lists.debian.org apache2-dev libapr1-dev Debian Cinnamon Team pkg-cinnamon-t...@lists.alioth.debian.org cinnamon cinnamon-settings-daemon Debian CLI Applications Team pkg-cli-apps-t...@lists.alioth.debian.org banshee-meego Debian FreeIPA Team pkg-freeipa-de...@lists.alioth.debian.org certmonger Debian Games Team pkg-games-de...@lists.alioth.debian.org freeorion funguloids Debian Gauche Maintainers pkg-gauche-de...@lists.alioth.debian.org gauche gauche-gl Debian GCC Maintainers debian-...@lists.debian.org libgnatprj4.9-dev Debian GNOME Maintainers pkg-gnome-maintain...@lists.alioth.debian.org gconf-defaults-service (U) gconf-service (U) gedit-plugins Debian GNUstep maintainers pkg-gnustep-maintain...@lists.alioth.debian.org gnustep-common libgnustep-base-dev Debian HA Maintainers debian-ha-maintain...@lists.alioth.debian.org heartbeat Debian Krap Maintainers debian-qt-...@lists.debian.org libqzeitgeist-dev virtuoso-opensource-6.1 Debian Med Packaging Team debian-med-packag...@lists.alioth.debian.org anfo libvxl1-dev Debian OCaml Maintainers debian-ocaml-ma...@lists.debian.org frama-c-base Debian Perl Group pkg-perl-maintain...@lists.alioth.debian.org libxml-parser-perl Debian Pkg-e Team pkg-e-de...@lists.alioth.debian.org e17 Debian Printing Group debian-print...@lists.debian.org foomatic-db-engine Debian Qt/KDE Maintainers debian-qt-...@lists.debian.org kdelibs5-dev libqca2-dev libqtruby4shared-dev libsmokeqt4-dev qt4-qmake qtmobility-dev Debian Science Maintainers debian-science-maintain...@lists.alioth.debian.org gerris-mpi libdiet-dagda2.8-dev libsoqt4-dev Debian Science Team debian-science-maintain...@lists.alioth.debian.org libcoin80-dev libdolfin-dev libsimage-dev ufc Debian SSSD Team pkg-sssd-de...@lists.alioth.debian.org sssd-dbus Debian systemd Maintainers pkg-systemd-maintain...@lists.alioth.debian.org systemd Debian VoIP Team pkg-voip-maintain...@lists.alioth.debian.org libpt-dev Debian WML Packaging Team pkg-wml-maintain...@lists.alioth.debian.org wml Debian X Strike Force debia...@lists.debian.org xserver-xorg-dev Debian Xfce Maintainers pkg-xfce-de...@lists.alioth.debian.org libexo-helpers orage thunar tumbler xfce4-cellmodem-plugin xfce4-linelight-plugin xfce4-messenger-plugin xfce4-netload-plugin xfce4-notifyd xfce4-quicklauncher-plugin xfce4-radio-plugin xfce4-sensors-plugin xfce4-timer-plugin xfce4-verve-plugin xfce4-wmdock-plugin xfce4-xkb-plugin xfconf xfswitch-plugin Debichem Team debichem-de...@lists.alioth.debian.org gromacs-dev Didier Raboud o...@debian.org foomatic-db-engine (U) Dirk Eddelbuettel e...@debian.org r-base-core Drew Parsons dpars...@debian.org gerris-mpi (U) xserver-xorg-dev (U) Eugen Dedu eugen.d...@pu-pm.univ-fcomte.fr libpt-dev (U) Evgeni Golov evg...@debian.org xfce4-cellmodem-plugin (U) xfce4-notifyd (U) Fabio Fantoni fantonifa...@tiscali.it cinnamon (U) cinnamon-settings-daemon (U) Fathi Boudra f...@debian.org kdelibs5-dev (U) qt4-qmake (U) qtmobility-dev (U) Felix Geyer fge...@debian.org libqca2-dev (U)
Re: Arch-dependent files in /usr/share
On Sun, Nov 02, 2014 at 06:33:15PM +0100, Jakub Wilk wrote: I found a number of arch!=all packages shipping /usr/share files that vary with architecture in a way indicating an FHS violation. Steve Langasek vor...@debian.org systemd-shim This is /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service, which is the sole location for declaring services to dbus (i.e., there is no corresponding path /usr/lib/dbus-1/system-services). The file varies by architecture because it encodes a reference to the binary daemon, which is shipped in a multiarch path. Since the package is not Multi-Arch: same anyway[1], and there will therefore only ever be one of these daemons on the system at a time, so we could ship it in /usr/lib instead of /usr/lib/$arch. But this also seems like a low-priority FHS issue to me. Is there a practical reason that we should treat these with a high priority? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] and obviously couldn't be with differing /usr/share contents signature.asc Description: Digital signature
Re: Arch-dependent files in /usr/share
* Steve Langasek (vor...@debian.org) [141102 19:39]: On Sun, Nov 02, 2014 at 06:33:15PM +0100, Jakub Wilk wrote: I found a number of arch!=all packages shipping /usr/share files that vary with architecture in a way indicating an FHS violation. Steve Langasek vor...@debian.org systemd-shim This is /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service, which is the sole location for declaring services to dbus (i.e., there is no corresponding path /usr/lib/dbus-1/system-services). The file varies by architecture because it encodes a reference to the binary daemon, which is shipped in a multiarch path. 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. (I however also don't think that this is pretty bad, but of course it is a FHS violation, and should be fixed.) Andi -- 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/20141102184210.gy20...@mails.so.argh.org
Re: Arch-dependent files in /usr/share
Le dimanche 02 novembre 2014 à 10:33 -0800, Steve Langasek a écrit : This is /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service, which is the sole location for declaring services to dbus (i.e., there is no corresponding path /usr/lib/dbus-1/system-services). The file varies by architecture because it encodes a reference to the binary daemon, which is shipped in a multiarch path. 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. We could move the binary to /usr/lib/gconf instead of /usr/lib/$triplet/gconf, but is there really a point? Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- 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/1414956762.28884.2.ca...@kagura.malsain.org
Re: Arch-dependent files in /usr/share
On Sun, 2 Nov 2014, Steve Langasek wrote: it in /usr/lib instead of /usr/lib/$arch. But this also seems like a low-priority FHS issue to me. Is there a practical reason that we should Low-priority sounds about right, but there’s still the supposed case of /usr/share sharing across architectures via NFS. bye, //mirabilos -- Why don't you use JavaScript? I also don't like enabling JavaScript in Because I use lynx as browser. +1 -- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel -- 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/alpine.deb.2.11.1411022059450.27...@tglase.lan.tarent.de
Re: Arch-dependent files in /usr/share
On Nov 02, Thorsten Glaser t...@debian.org wrote: Low-priority sounds about right, but there’s still the supposed case of /usr/share sharing across architectures via NFS. So much hypothetical that I am quite sure that nobody does this. -- ciao, Marco signature.asc Description: Digital signature
Re: Arch-dependent files in /usr/share
On 2014-11-02, Josselin Mouette j...@debian.org wrote: Le dimanche 02 novembre 2014 à 10:33 -0800, Steve Langasek a écrit : This is /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service, which is the sole location for declaring services to dbus (i.e., there is no corresponding path /usr/lib/dbus-1/system-services). The file varies by architecture because it encodes a reference to the binary daemon, which is shipped in a multiarch path. 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. And for various .desktop files All the cmake files in the list, on the other hand, should be shippable in /usr/lib/ I'm not sure about all the lintian overrides in there. Maybe a fix needs to be applied in lintian for arch specific overrides ? /Sune -- 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/m36663$5uc$1...@ger.gmane.org
Re: Arch-dependent files in /usr/share
m...@linux.it (Marco d'Itri) writes: On Nov 02, Thorsten Glaser t...@debian.org wrote: Low-priority sounds about right, but there’s still the supposed case of /usr/share sharing across architectures via NFS. So much hypothetical that I am quite sure that nobody does this. Yeah, at the point where you're so space-constrained on a device that you're doing this, you probably just mount all of /usr from the network, and as soon as you have real storage, it's easy enough to just have one full copy of /usr per architecture (and probably a lot safer and more reliable). Honestly, I think the /usr/share vs. /usr/lib distinction in the FHS may have outlived its usefulness. The only other thing that I know people do with it is check /usr/lib in Tripwire but not check /usr/share, and I'm not sure that makes any sense either. It's tempting to just use /usr/lib for everything and let /usr/share die, but the transition is hideous and a ton of tedious work. Meh. So... we shouldn't gratuitously break the distinction, but it does make me question how much effort we should put into fixing issues like this. We could add a search path to D-Bus to check both /usr/share and /usr/lib, and in a lot of ways that's the simplest fix, but if we could eventually eliminate this distinction, it would remove a bunch of Lintian checking and package machinery and moving stuff about that's of rather questionable usefulness and mostly just wastes maintainer time. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/878ujt71mv@hope.eyrie.org
Re: Arch-dependent files in /usr/share
On Nov 02, Russ Allbery r...@debian.org wrote: So... we shouldn't gratuitously break the distinction, but it does make me question how much effort we should put into fixing issues like this. We Agreed. -- ciao, Marco signature.asc Description: Digital signature
Re: Arch-dependent files in /usr/share
Sune Vuorela nos...@vuorela.dk writes: All the cmake files in the list, on the other hand, should be shippable in /usr/lib/ I'm not sure about all the lintian overrides in there. Maybe a fix needs to be applied in lintian for arch specific overrides ? I think it's worth considering whether we should just dump the Lintian checks for arch-independent files in /usr/lib, and make a corresponding change to Policy that says that packages are free to put arch-independent files there. No one is ever going to bother to move the files in, say, LibreOffice into /usr/share, since the theoretical gain totally isn't worth the effort in maintaining the package. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/874muh71jl@hope.eyrie.org
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 (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
Re: Arch-dependent files in /usr/share
Hi, On Sun, Nov 02, 2014 at 01:09:02PM -0800, Russ Allbery wrote: files there. No one is ever going to bother to move the files in, say, LibreOffice into /usr/share, since the theoretical gain totally isn't worth the effort in maintaining the package. Actually I have various hacks in LibreOffice packaging doing exactly this. (Admittedly not all, and that rest is would be the most painful one.) Regards, Rene -- 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/20141102230734.gc18...@rene-engelhard.de
Re: Arch-dependent files in /usr/share
Rene Engelhard r...@debian.org writes: On Sun, Nov 02, 2014 at 01:09:02PM -0800, Russ Allbery wrote: files there. No one is ever going to bother to move the files in, say, q LibreOffice into /usr/share, since the theoretical gain totally isn't worth the effort in maintaining the package. Actually I have various hacks in LibreOffice packaging doing exactly this. (Admittedly not all, and that rest is would be the most painful one.) Ah, I'd only noticed the remaining ones and hadn't realized all the work you were already doing. Sorry about that! But the broader point is that if we stopped requiring this distinction, you could unwind those hacks as well. My guess is that would make maintaining the packages easier and would be preferrable from your perspective, although please do correct me if I'm wrong about that. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87mw895hbj@hope.eyrie.org
Re: Arch-dependent files in /usr/share
Hi, On Sun, Nov 02, 2014 at 03:11:12PM -0800, Russ Allbery wrote: But the broader point is that if we stopped requiring this distinction, you could unwind those hacks as well. My guess is that would make maintaining the packages easier and would be preferrable from your perspective, although please do correct me if I'm wrong about that. Indeed, you are right. Even the existing ones gave headaches at times (especially the icons/images_* which broke not that long ago when being in /usr/share (well, actually being symlinks...). Regards, Rene -- 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/20141102231815.gd18...@rene-engelhard.de
Re: Arch-dependent files in /usr/share
* Sune Vuorela nos...@vuorela.dk, 2014-11-02, 21:02: I'm not sure about all the lintian overrides in there. Maybe a fix needs to be applied in lintian for arch specific overrides ? You can use wildcards in Lintian overrides. For example, instead of emacs24-bin-common binary: setgid-binary usr/lib/emacs/24.4/x86_64-linux-gnu/movemail 2755 root/mail you can write emacs24-bin-common binary: setgid-binary usr/lib/emacs/24.4/*/movemail 2755 root/mail -- Jakub Wilk -- 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/20141102233610.ga9...@jwilk.net
RE: Arch-dependent files in /usr/share
Good catch. -Original Message- From: Jakub Wilk jw...@debian.org Sent: 11/2/2014 12:33 PM To: debian-devel@lists.debian.org debian-devel@lists.debian.org Subject: Arch-dependent files in /usr/share I found a number of arch!=all packages shipping /usr/share files that vary with architecture in a way indicating an FHS violation. DD-list of the affect binary packages is attached, and diff between i386 and s390x is here: https://people.debian.org/~jwilk/qa/20141101-usr-share.diff Please fix your packages. :-) -- Jakub Wilk
Re: Arch-dependent files in /usr/share
* Russ Allbery r...@debian.org [141102 22:12]: Sune Vuorela nos...@vuorela.dk writes: All the cmake files in the list, on the other hand, should be shippable in /usr/lib/ I'm not sure about all the lintian overrides in there. Maybe a fix needs to be applied in lintian for arch specific overrides ? I think it's worth considering whether we should just dump the Lintian checks for arch-independent files in /usr/lib, and make a corresponding change to Policy that says that packages are free to put arch-independent files there. I agree. The various interpreters already ship most of their standard library files in /usr/lib. I'd also want to point out that additional search paths in /usr/share would add significant runtime overhead. -- ,''`. Christian Hofstaedtler z...@debian.org : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- -- 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/20141103013236.ga19...@nq.home.zeha.at
Re: Arch-dependent files in /usr/share
Russ Allbery wrote: I think it's worth considering whether we should just dump the Lintian checks for arch-independent files in /usr/lib, and make a corresponding change to Policy that says that packages are free to put arch-independent files there. See bug 741304; that change occurred in Policy 3.9.6.0, and lintian should change to match. - Josh Triplett -- 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/20141103023738.GA20359@thin
Re: Arch-dependent files in /usr/share
Josh Triplett j...@joshtriplett.org writes: Russ Allbery wrote: I think it's worth considering whether we should just dump the Lintian checks for arch-independent files in /usr/lib, and make a corresponding change to Policy that says that packages are free to put arch-independent files there. See bug 741304; that change occurred in Policy 3.9.6.0, and lintian should change to match. Not quite. That still requires moving whole directories to /usr/lib (at normal severity level). I'm saying that we should consider waiving this section of the FHS completely and letting packagers use /usr/lib for arch-independent files. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- 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/87lhnt3sel@hope.eyrie.org
