Debian Bug report logs - #512645
[checks/manpages] missing man pages reported for foo that are in foo-data

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Fabian Greffrath <greffrath@leat.rub.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: lintian reports errors in package foo, because it does not honor files in the foo-data package, on which foo depends

Date: Thu, 22 Jan 2009 16:02:35 +0100

Package: lintian
Severity: minor
Version: 2.1.5

Dear lintian maintainers,

sorry for the subject line, but my concern is a little bit too 
complicated to describe it in one line, I guess. ;)

Imagine I build a package foo, which consists of a binary in /usr/bin 
and architecture-independent content in /usr/share. Since the stuff in 
/usr/share takes quite a lot of space (think of files in 
/usr/share/locale) I want to put it in an arch:all package called 
foo-data. To achieve this I tell foo's Makefile that it must install 
into destdir=$CURDIR)/debian/tmp; then I create a debian/foo.install 
file containing the line "debian/tmp/usr/bin" and a 
debian/foo-data.install file that contains "debian/tmp/usr/share". Of 
course foo now also needs to depend on foo-data which I achieve by 
adding "foo-data (=${source:Version})" to foo's Depends line in 
debian/control. Alright, nothing new so far.

But now, if I run lintian on the newly created packages, I get 
warnings like "binary-without-manpage: usr/bin/foo" which simply isn't 
true. There *is* a manpage for /usr/bin/foo, it simply isn't installed 
in the foo package but in the foo-data package and I even made sure 
that foo does not get installed without foo-data.

Could you please make lintian check if there is a package (foo-data) 
created from the same source that contains the obviously missing files 
and if the assumed faulty package (foo) depends on this package 
(foo-data)?

Thank you very much!

Cheers,
Fabian

-- 
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax:     +49 (0)234 / 32-14227
E-Mail:  greffrath@leat.ruhr-uni-bochum.de

Message #10 received at 512645@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Fabian Greffrath <greffrath@leat.rub.de>

Cc: 512645@bugs.debian.org

Subject: Re: Bug#512645: lintian reports errors in package foo, because it does not honor files in the foo-data package, on which foo depends

Date: Thu, 22 Jan 2009 11:12:05 -0800

severity 512645 wishlist
merge 512645 120323
retitle 512645 [checks/manpages] missing man pages reported for foo that are in foo-data
thanks

Fabian Greffrath <greffrath@leat.rub.de> writes:

> But now, if I run lintian on the newly created packages, I get warnings
> like "binary-without-manpage: usr/bin/foo" which simply isn't
> true. There *is* a manpage for /usr/bin/foo, it simply isn't installed
> in the foo package but in the foo-data package and I even made sure that
> foo does not get installed without foo-data.

Right, the problem is that Lintian checks a package at a time, so while
it's checking foo, it has no access to foo-data.  Lintian is designed to
check each package in isolation.  It's difficult to do more than that and
still support things like lintian.d.o.

That being said, there is a possible hack that we can apply here that may
fix the common case of checking a *.changes file for a set of related
packages and on lintian.d.o.  See the discussion in #456657 for more
details.

This is why binary-without-manpage explicitly says to add an override for
this case, though.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #15 received at 512645@bugs.debian.org (full text, mbox, reply):

From: Fabian Greffrath <greffrath@leat.rub.de>

To: Russ Allbery <rra@debian.org>

Cc: 512645@bugs.debian.org

Subject: Re: Bug#512645: lintian reports errors in package foo, because it does not honor files in the foo-data package, on which foo depends

Date: Fri, 23 Jan 2009 09:33:45 +0100

Hello Russ,

Russ Allbery schrieb:
> Right, the problem is that Lintian checks a package at a time, so while
> it's checking foo, it has no access to foo-data.  Lintian is designed to
> check each package in isolation.  It's difficult to do more than that and
> still support things like lintian.d.o.

OK, I see...

> That being said, there is a possible hack that we can apply here that may
> fix the common case of checking a *.changes file for a set of related
> packages and on lintian.d.o.  See the discussion in #456657 for more
> details.

Well, I have no clue about lintian internals, but isn't the check for 
the dangling /usr/lib/libfoo.so -> /usr/lib/libfoo.so.$SONAME in 
libfoo-dev packages a similar exception? At least it throws no error 
if /usr/lib/libfoo.so.$SONAME does exist in the libfoo$SONAME package 
and libfoo-dev depends on it.

> This is why binary-without-manpage explicitly says to add an override for
> this case, though.

The binary-without-manpage warning is only the simplest one that 
crossed my mind. A more complicated example is realted to 
debian/foo.menu files.

Imagine the same situation than before: A binary /usr/bin/foo in the 
foo package and all arch-indep content of /usr/share in the foo-data 
package. foo denepds on foo-data.
Now I add a debian/foo.menu file which contains the lines 
'command="/usr/bin/foo"' and 'icon="/usr/share/pixmaps/foo.xpm"'. Of 
course, since the file /usr/share/pixmaps/foo.xpm cannot be found in 
the foo package, lintian throws the menu-icon-missing warning. This 
will be another lintian overrides. :/
On the other hand, if I move the menu file to debian/foo-data.menu, 
the menu-icon-missing warning will be gone, but the 
menu-command-not-in-package warning will appear instead, since 
/usr/bin/foo is not part of foo-data. Even worse, I cannot make 
foo-data depend on foo, because I have to avoid circular dependencies. 
So all I can do is make foo-data recommend foo, but then it is still 
possible that a user mistakenly install foo-data without foo and ends 
up with a dead menu entry.

Please, I really don't want to add a bunch of lintian overrides for 
reasonably packaged split-up packages. ;)

Cheers,
Fabian


-- 
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax:     +49 (0)234 / 32-14227
E-Mail:  greffrath@leat.ruhr-uni-bochum.de

Message #20 received at 512645@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Fabian Greffrath <greffrath@leat.rub.de>

Cc: 512645@bugs.debian.org

Subject: Re: Bug#512645: lintian reports errors in package foo, because it does not honor files in the foo-data package, on which foo depends

Date: Fri, 23 Jan 2009 12:06:56 -0800

Fabian Greffrath <greffrath@leat.rub.de> writes:
> Russ Allbery schrieb:

>> That being said, there is a possible hack that we can apply here that
>> may fix the common case of checking a *.changes file for a set of
>> related packages and on lintian.d.o.  See the discussion in #456657 for
>> more details.

> Well, I have no clue about lintian internals, but isn't the check for
> the dangling /usr/lib/libfoo.so -> /usr/lib/libfoo.so.$SONAME in
> libfoo-dev packages a similar exception? At least it throws no error if
> /usr/lib/libfoo.so.$SONAME does exist in the libfoo$SONAME package and
> libfoo-dev depends on it.

Lintian intentionally doesn't check for dangling symlinks at all because
of this issue.  See #217023.

>> This is why binary-without-manpage explicitly says to add an override
>> for this case, though.
>
> The binary-without-manpage warning is only the simplest one that crossed
> my mind. A more complicated example is realted to debian/foo.menu files.

In this case, I think you should keep the menu package in the binary
package and not move it to the data package.  (Honestly, I would do the
same thing with the man pages as well.)  There really isn't a need to move
everything into /usr/share, only the large data.  Man pages and menu files
are small and don't waste much space in the binary package, and I would
just leave them there.

Otherwise, you can add an override here as well.

> Please, I really don't want to add a bunch of lintian overrides for
> reasonably packaged split-up packages. ;)

I understand your concern, but it's unlikely that Lintian is going to
change in any significant way in this area.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #31 received at 512645@bugs.debian.org (full text, mbox, reply):

From: Fabian Greffrath <greffrath@leat.rub.de>

To: Russ Allbery <rra@debian.org>

Cc: 512645@bugs.debian.org

Subject: Re: Bug#512645: lintian reports errors in package foo, because it does not honor files in the foo-data package, on which foo depends

Date: Mon, 26 Jan 2009 08:54:35 +0100

Russ Allbery schrieb:
> Lintian intentionally doesn't check for dangling symlinks at all because
> of this issue.  See #217023.

Oh, I didn't know this.

> In this case, I think you should keep the menu package in the binary
> package and not move it to the data package.  (Honestly, I would do the
> same thing with the man pages as well.)  There really isn't a need to move
> everything into /usr/share, only the large data.  Man pages and menu files
> are small and don't waste much space in the binary package, and I would
> just leave them there.

This is what I did, i.e. I put parts of /usr/share in the foo-data 
package and other parts like /usr/share/{applications,pixmaps,man} in 
the foo package to get rid of lintian warning. However, this is what I 
initially wanted to avoid, i.e. mix up arch-indep stuff between 
arch:any and arch:all packages.

> Otherwise, you can add an override here as well.

This is what I wanted to avoid, too.

> I understand your concern, but it's unlikely that Lintian is going to
> change in any significant way in this area.

Alright, but it feels good having talked about it. ;) I'll leave the 
bug report open, though.

Cheers,
Fabian


-- 
Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax:     +49 (0)234 / 32-14227
E-Mail:  greffrath@leat.ruhr-uni-bochum.de

Send a report that this bug log contains spam.