Bug#415558: lintian: too pedantic about /usr/lib vs. /usr/share (image-file-in-usr-lib)

[Ole Streicher]

Hi,

On debian-python, there just was a discussion about where to put python
packages, and the common agreement is that they should go completely to
/usr/lib.

This included f.e. images that are distributed within the package tree.
Also, the Debian Policy now (3.9.6 -- see #741304) allows to put whole
package trees (including data) into /usr/lib.

Therefore, having an image in /usr/lib is not (longer) a reason to warn; the
severity should be lowered to "info".

Best regards

Ole


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#415558: lintian: too pedantic about /usr/lib vs. /usr/share (image-file-in-usr-lib)

[Colin Watson]

On Sat, Mar 24, 2007 at 03:04:03PM +0100, Marc 'HE' Brockschmidt wrote:
> Colin Watson <[EMAIL PROTECTED]> writes:
> > Don't get me wrong: I'm not saying that we should fail to fix bugs just
> > because "it's too much effort". Nor am I saying that the effort expended
> > so far on moving files to /usr/share is wasted; hierarchies such as
> > /usr/share/doc, /usr/share/fonts, and /usr/share/man are a very
> > substantial win on heterogeneous shared systems. However, I do think
> > that we're rapidly approaching diminishing returns on this. When the
> > lintian warning is for a single image file in /usr/lib that requires
> > fiddly build system changes to move (or fragile hacks in debian/ that
> > would be liable to break on each new upstream version), I question
> > whether this is a sensible use of developer time, and I question whether
> > it really buys anything for administrators of heterogeneous systems.
> 
> I think that Debian's commitment to policies, even if it is hard work to
> adhere to them, is one of the few things that Debian still has as
> an advantage over other distributions. I don't see why we should stop to
> nag maintainers to work on these issues.

I'm not opposed to this, but frankly I think that this is a stupid
policy, at least when taken to this extent. Adherence to stupid policies
isn't an advantage. (I do not think this about most of Debian's
policies; this is an exception.)

> Anyway, as Russ said, this is not an issue that should be decided
> without having a discussion somewhere else, but I have to admit that I'm
> against such a change.

Fair enough.

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#415558: lintian: too pedantic about /usr/lib vs. /usr/share (image-file-in-usr-lib)

[Marc 'HE' Brockschmidt]

Colin Watson <[EMAIL PROTECTED]> writes:
> Don't get me wrong: I'm not saying that we should fail to fix bugs just
> because "it's too much effort". Nor am I saying that the effort expended
> so far on moving files to /usr/share is wasted; hierarchies such as
> /usr/share/doc, /usr/share/fonts, and /usr/share/man are a very
> substantial win on heterogeneous shared systems. However, I do think
> that we're rapidly approaching diminishing returns on this. When the
> lintian warning is for a single image file in /usr/lib that requires
> fiddly build system changes to move (or fragile hacks in debian/ that
> would be liable to break on each new upstream version), I question
> whether this is a sensible use of developer time, and I question whether
> it really buys anything for administrators of heterogeneous systems.

I think that Debian's commitment to policies, even if it is hard work to
adhere to them, is one of the few things that Debian still has as
an advantage over other distributions. I don't see why we should stop to
nag maintainers to work on these issues.

Anyway, as Russ said, this is not an issue that should be decided
without having a discussion somewhere else, but I have to admit that I'm
against such a change.

Marc
-- 
BOFH #228:
That function is not currently supported, but Bill Gates assures us
it will be featured in the next upgrade.


pgpcNp12Ydo77.pgp
Description: PGP signature

Bug#415558: lintian: too pedantic about /usr/lib vs. /usr/share (image-file-in-usr-lib)

[Russ Allbery]

Colin Watson <[EMAIL PROTECTED]> writes:

> However, I do think image-file-in-usr-lib ought to be downgraded to an
> informative message. It's the sort of thing that bites in all sorts of
> random packages (see
> http://lintian.debian.org/reports/Timage-file-in-usr-lib.html) and is
> typically fiddly and varied to deal with, and a lot of the images
> involved are little things like icons where the effort doesn't really
> justify the gain; if they were embedded into executables, we likely
> wouldn't care.

> It's been a while since I was particularly involved in lintian
> maintenance, so I don't feel that I can change this unilaterally. What
> do the other lintian maintainers think of my position?

This is really a broader question than just lintian.  Packages have been
rejected by ftp-master for things like this before, and it doesn't do
people any good for us to relax our warning if ftp-master is still going
to reject packages.

It does look like the FHS gives us leeway to put arch-independent files
into /usr/lib at the discretion of the packager, so as near as I can tell
this isn't a direct policy violation.  But I'd really like to see some
debian-devel or debian-policy discussion of this and some opinion from
ftp-master about what level they're willing to enforce before we make a
change.

-- 
Russ Allbery ([EMAIL PROTECTED])   


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#415558: lintian: too pedantic about /usr/lib vs. /usr/share (image-file-in-usr-lib)

[Colin Watson]

Package: lintian
Version: 1.23.27
Severity: wishlist

lintian warns in a couple of places about files being placed in /usr/lib
vs. /usr/share. While I appreciate that the FHS says "The /usr/share
hierarchy is for all read-only architecture independent data files", I
nevertheless think that these warnings are too pedantic.

Consider the intent of /usr/share. An administrator of many systems of
heterogeneous architectures is intended to be able to share the
/usr/share directory among them, for example using NFS. If one places
architecture-dependent files in /usr/share, then clearly that is a bug
because it certainly defeats that purpose. However, placing an
architecture-independent file in /usr/lib or elsewhere merely wastes a
little disk space on such systems. In some cases (e.g. menu files, small
images, etc.), the amount of disk space involved is truly negligible in
comparison to the amount of disk space required for the entire
installation. In many cases, it is not at all clear to me that it is
truly worth the developer time and potential for introducing new bugs
required to move the files.

Don't get me wrong: I'm not saying that we should fail to fix bugs just
because "it's too much effort". Nor am I saying that the effort expended
so far on moving files to /usr/share is wasted; hierarchies such as
/usr/share/doc, /usr/share/fonts, and /usr/share/man are a very
substantial win on heterogeneous shared systems. However, I do think
that we're rapidly approaching diminishing returns on this. When the
lintian warning is for a single image file in /usr/lib that requires
fiddly build system changes to move (or fragile hacks in debian/ that
would be liable to break on each new upstream version), I question
whether this is a sensible use of developer time, and I question whether
it really buys anything for administrators of heterogeneous systems.

Most of the warnings in question are simple transitions in progress that
are largely handled by a single debhelper command (menu-file-in-usr-lib)
or are confined to a small group of packages
(package-installs-nonbinary-perl-in-usr-lib-perl5). I'm not so bothered
about those, since the practices for dealing with them are pretty
established now.

However, I do think image-file-in-usr-lib ought to be downgraded to an
informative message. It's the sort of thing that bites in all sorts of
random packages (see
http://lintian.debian.org/reports/Timage-file-in-usr-lib.html) and is
typically fiddly and varied to deal with, and a lot of the images
involved are little things like icons where the effort doesn't really
justify the gain; if they were embedded into executables, we likely
wouldn't care.

It's been a while since I was particularly involved in lintian
maintenance, so I don't feel that I can change this unilaterally. What
do the other lintian maintainers think of my position?

Thanks,

-- 
Colin Watson   [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]