Re: RFH lintian too hush
On Sun, Aug 29, 2004 at 07:26:35PM +0200, Jeroen van Wolffelaar wrote:
> On Sun, Aug 29, 2004 at 05:10:21PM +0200, Geert Stappers wrote:
<snip what="warnings found by others, but by me"/>
> > According the manual page of lintian is there a check for "huge /usr/share".
> > Conglomerate 0.7.14-1 is about 1.4 Mb with a 1.2Mb /usr/share,
> > but lintian didn't complain about that huge /usr/share.
> > IMNSHO it makes sense to at least warn about a u.s. of more one megabyte.
> > Did I use lintian incorrect
Oops, indeed I didn't tell that I didn't provide any optional flags.
> > or is it triggered at a larger /usr/share ?
> > (then please tell me at which size )
> Please tell use HOW you use lintian if you want to know IF you used it
> incorrect, I cannot magically see how you use lintian.
( wget http://www.stappers.nl/gst/pool/main/c/conglomerate/conglomerate_0.7.14-1_powerpc.deb )
So no extra flags. That is based on lintian manual page.
Run all checks over the specified packages. This is the default
The idea is the use the default action to get _all_ checks.
But I was looking for the hugh /usr/share so I tried
lintian -C hus conglomerate_0.7.14-1_powerpc.deb
Two snippets from the lintian manual page
-C chk1,chk2,..., --check-part chk1,chk2,...
Run only the specified checks. You can either specify the name
of the check script or the abbreviation. For details, see the
CHECKS section below.
Checks whether an architecture-dependent package does have a
significantly big /usr/share. Big amounts of architecture inde-
pendent data in architecture dependent packages waste space on
But still no sign of the hugh /usr/share
> Regarding this check, see /usr/share/lintian/checks/huge-usr-share, and
> note that due to its new, experimental nature, it is only displayed when
> you enable informative checks, by means of lintian -I.
Hey a -I flag, lets try it:
$ lintian -I conglomerate_0.7.14-1_powerpc.deb
I: conglomerate: arch-dep-package-has-big-usr-share 4448kB 86%
Okay, I found what I was looking for ....
What is a constructive way to solve our different expections
of _all_ checks and "forceing hus check" versus the -I flag?
(next is dutch, native language for me and probably also for Jeroen
Wat is een opbouwende manier om ons verschil in verwachtingen
bij _alle_ test en de "geforceerde hus test" tegenover
de -I optie op te lossen?)