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
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
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
* 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
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
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
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
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
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
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
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
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
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
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.
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
* 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
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
* 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
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
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
20 matches
Mail list logo
