Re: Re: Arch-dependent files in /usr/share

[Jonathan de Boyne Pollard]

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

Re: Arch-dependent files in /usr/share

[Russ Allbery]

Josh Triplett  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)   


-- 
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

Re: Arch-dependent files in /usr/share

[Josh Triplett]

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

[Christian Hofstaedtler]

* Russ Allbery  [141102 22:12]:
> Sune Vuorela  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 
: :' :  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

[Saqman2060]

Good catch.

-Original Message-
From: "Jakub Wilk" 
Sent: ‎11/‎2/‎2014 12:33 PM
To: "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

[Jakub Wilk]

* Sune Vuorela , 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

[Rene Engelhard]

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

[Russ Allbery]

Rene Engelhard  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)   


-- 
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

[Rene Engelhard]

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

[Simon McVittie]

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

[Russ Allbery]

Sune Vuorela  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)   


-- 
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

[Marco d'Itri]

On Nov 02, Russ Allbery  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

[Russ Allbery]

m...@linux.it (Marco d'Itri) writes:
> On Nov 02, Thorsten Glaser  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)   


--
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

[Sune Vuorela]

On 2014-11-02, Josselin Mouette  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

[Marco d'Itri]

On Nov 02, Thorsten Glaser  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

[Thorsten Glaser]

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

[Josselin Mouette]

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

[Andreas Barth]

* 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 
> >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

[Steve Langasek]

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 
>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