FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 12-04-2008, 08:00 AM
Russ Allbery
 
Default Possibly excessive lintian warnings (was: NEW processing)

Sune Vuorela <nospam@vuorela.dk> writes:

> Latest, the warning about quilt patches without any description. Sure it
> is nice to have a description, but I don't need lintian to tell it.

This is severity: minor, certainty: certain, which currently *barely*
makes the W threshold. I think a very good argument could be made that
this is actually severity: wishlist, which would downgrade it to an I.
I'm copying debian-lint-maint to see what the other Lintian maintainers
think.

I do think the warning is correct for a lint program, and it sounds like
you do agree that this is something that should be improved about the
package. The prioritization just may be off.

> and in other words, the latest package I uploaded:
>
> $ lintian kdebase_3.5.9.dfsg.1-6_i386.changes | wc --lines && lintian
> kdebase_3.5.9.dfsg.1-6_i386.changes | tail -1
> 142
> N: 58 tags overridden (32 errors, 26 warnings)

http://lintian.debian.org/full/debian-qt-kde@lists.debian.org.html#kdebase

Much of this is just more of the desktop file fiasco, since KDE doesn't
follow what's supposedly a shared standard. I've complained about that at
some length before and don't know what people are supposed to do with
desktop files. If anyone from the KDE team is willing to propose patches
or even concrete actionable changes to how Lintian checks desktop files so
that KDE's desktop files don't produce tons of noise, I'd love to hear
them.

You don't have man pages for many of your programs, as you've noted, which
is pile of warnings.

You install libraries into /usr/lib in a bunch of packages without shlibs
entries and don't call ldconfig in postinst. Hm, and you override that in
a few places. In general, just looking at the Lintian report, I don't
understand what you're doing with shared libraries and why it's correct.
Lintian thinks it's wrong, and I understand why Lintian thinks it's wrong,
but I must be missing something (which Lintian is also missing).

You're apparently not using detached symbols for your debugging libraries,
which is another small pile of warnings.

By and large, apart from the desktop mess and whatever is going on with
shared libraries that I don't understand, the Lintian report looks like a
lot of work that should ideally be done on the packages. I'm not really
seeing stuff that's obviously wrong, although I only looked at it
cursorily.

> You are most welcome to join in and help fixing issues and especially
> writing manpages. and then, there is the ~1500 open bug reports.

You have a huge and difficult-to-package piece of software and inadequate
resources to do all the work on it that should ideally be done. I get
that, and I'm not criticizing what you're doing. But I don't think that
Lintian should stay silent about issues just because there isn't enough
time to correct them. It shouldn't complain about things that aren't
actually issues, but it should complain about the things that need to be
fixed, even if they can't be fixed right away. That's what it's for.

Not having a man page for a binary is a Policy violation. If Lintian
doesn't complain about Policy violations, it's hard to understand what the
point of it would be. There's a reason why that's a warning and not an
error, though.

> Please stop making the lives for the developers harder. Especially the
> idea about automatically rejecting based on lintian.

The only thing that's been seriously discussed with an eye to
implementation, so far as I know, is to automatically reject on the basis
of a hand-selected and very limited subset of Lintian tags, which would
probably not affect anything that you're doing and which would certainly
not automatically block packages with proper overrides. I don't think
this is going to hurt you as much as you think it would.

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


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-04-2008, 08:22 AM
"Adam D. Barratt"
 
Default Possibly excessive lintian warnings (was: NEW processing)

On Thu, 04 Dec 2008 01:00:17 -0800, Russ Allbery wrote:

Sune Vuorela <nospam@vuorela.dk> writes:


Latest, the warning about quilt patches without any description.
Sure it is nice to have a description, but I don't need lintian to
tell it.


This is severity: minor, certainty: certain, which currently *barely*
makes the W threshold. I think a very good argument could be made
that this is actually severity: wishlist, which would downgrade it to
an I. I'm copying debian-lint-maint to see what the other Lintian
maintainers think.


As I mentioned to Sune on IRC last night, the quilt tag's severity was
copied from the equivalent dpatch tag (which was originally implemented as a
warning and then moved to minor/certain during the transition).


I've no problem with downgrading the severity, although we should make a
corresponding change to the dpatch tag at the same time, unless there's some
reason it's particularly worse for a dpatch to be missing a description.


Adam



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-04-2008, 08:39 AM
Sune Vuorela
 
Default Possibly excessive lintian warnings (was: NEW processing)

On 2008-12-04, Russ Allbery <rra@debian.org> wrote:
> Sune Vuorela <nospam@vuorela.dk> writes:
>
>> Latest, the warning about quilt patches without any description. Sure it
>> is nice to have a description, but I don't need lintian to tell it.
>
> I do think the warning is correct for a lint program, and it sounds like
> you do agree that this is something that should be improved about the
> package. The prioritization just may be off.

Yes. downgrading to I is a good solution.

And other warnings that could be changed:
dbg-package-missing-depends - if there 1 dbg package and multiple
arch depending packages beside that.

> Much of this is just more of the desktop file fiasco, since KDE doesn't
> follow what's supposedly a shared standard. I've complained about that at
> some length before and don't know what people are supposed to do with
> desktop files. If anyone from the KDE team is willing to propose patches
> or even concrete actionable changes to how Lintian checks desktop files so
> that KDE's desktop files don't produce tons of noise, I'd love to hear
> them.

A good solution is to get lenny out of the door so that we can ditch
kde3 and go on with kde4. KDE4 do follow the specs. Kde3 originates
from before it was a shared standard (one of the few fdo standards that
is actually a *shared* standard and not a rubber stamp on gnome
standards, but that's a entirely different issue)

> You're apparently not using detached symbols for your debugging libraries,
> which is another small pile of warnings.

we are, but apparantly dh_strip has issues under some conditions with
some of the files.

> You have a huge and difficult-to-package piece of software and inadequate
> resources to do all the work on it that should ideally be done. I get

This is why I need automatic tools that *helps* me and not tools that
gets in the way.

> Not having a man page for a binary is a Policy violation. If Lintian
> doesn't complain about Policy violations, it's hard to understand what the
> point of it would be. There's a reason why that's a warning and not an
> error, though.

It is also one of the reasons why we aren't overriding that.

>> Please stop making the lives for the developers harder. Especially the
>> idea about automatically rejecting based on lintian.
>
> The only thing that's been seriously discussed with an eye to
> implementation, so far as I know, is to automatically reject on the basis
> of a hand-selected and very limited subset of Lintian tags, which would
> probably not affect anything that you're doing and which would certainly
> not automatically block packages with proper overrides. I don't think
> this is going to hurt you as much as you think it would.

Some people in this thread are suggesting automatic rejecting based on any E: tag.

/Sune


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-04-2008, 07:49 PM
Raphael Geissert
 
Default Possibly excessive lintian warnings (was: NEW processing)

Sune Vuorela wrote:
[...]
>
> And other warnings that could be changed:
> dbg-package-missing-depends - if there 1 dbg package and multiple
> arch depending packages beside that.
>

Will try to work on a dh-like command (or maybe a patch against dh_strip,
depends on what Joey prefers) that will basically scan
debian/*/foo-dbg/usr/lib/debug/(*) and try to find a file under debian/*/
matching the subgrouped expression, to automagically generate the Depends field
(say ${dbgepends}).

Once that's done it would be just a matter of adjusting a couple of lines in
debian/control and you are done with dealing with -dbg packages.

Cheers,
Raphael Geissert



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-04-2008, 07:58 PM
Sune Vuorela
 
Default Possibly excessive lintian warnings (was: NEW processing)

On 2008-12-04, Raphael Geissert <atomo64+debian@gmail.com> wrote:
> Will try to work on a dh-like command (or maybe a patch against dh_strip,
> depends on what Joey prefers) that will basically scan
> debian/*/foo-dbg/usr/lib/debug/(*) and try to find a file under debian/*/
> matching the subgrouped expression, to automagically generate the Depends field
> (say ${dbgepends}).
>
> Once that's done it would be just a matter of adjusting a couple of lines in
> debian/control and you are done with dealing with -dbg packages.

No. it actually wouldn't work.

In kde, for example kdepim, contains applications like
- korganizer
- kaddressbook
- kmail
- kpilot

With a -dbg package depending on all apps, the user will have to install
all apps just for getting a backtrace for one application.

That is not desired.
Bloating the archive with seperated -dbg packages is ttbomk not desired
as well.

The current approach is currently the least bad, and lintian should not
complain.

/Sune


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-04-2008, 08:17 PM
Raphael Geissert
 
Default Possibly excessive lintian warnings (was: NEW processing)

Sune Vuorela wrote:

> On 2008-12-04, Raphael Geissert <atomo64+debian@gmail.com> wrote:
>> Will try to work on a dh-like command (or maybe a patch against dh_strip,
>> depends on what Joey prefers) that will basically scan
>> debian/*/foo-dbg/usr/lib/debug/(*) and try to find a file under debian/*/
>> matching the subgrouped expression, to automagically generate the Depends
>> field (say ${dbgepends}).

Using ORed depends, I forgot to say.

>>
>> Once that's done it would be just a matter of adjusting a couple of lines in
>> debian/control and you are done with dealing with -dbg packages.
>
> No. it actually wouldn't work.
>
> In kde, for example kdepim, contains applications like
> - korganizer
> - kaddressbook
> - kmail
> - kpilot
>
> With a -dbg package depending on all apps, the user will have to install
> all apps just for getting a backtrace for one application.
>
> That is not desired.
> Bloating the archive with seperated -dbg packages is ttbomk not desired
> as well.

Of course.

>
> The current approach is currently the least bad, and lintian should not
> complain.

I don't agree, -dbg packages all by themselves are completely useless, they MUST
depend on something that will actually make them meaningful. Otherwise they
should not be built/shipped.

>
> /Sune

Cheers,
Raphael Geissert



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-04-2008, 08:25 PM
Sune Vuorela
 
Default Possibly excessive lintian warnings (was: NEW processing)

On 2008-12-04, Raphael Geissert <atomo64+debian@gmail.com> wrote:
> Using ORed depends, I forgot to say.

How would OR'ed depends work?

let us look at a example:

package: kdepim-dbg
depends: korganizer (= ${binary:Version})|kaddressbook (=${binary:version})
version: 4.1.3-1

now, I install korganizer 4.1.3-1 and kdepim-dbg.
later, 4.1.3-2 gets uploadde and I install kaddressbook.
korganizer still fulfills the kdepim-dbg version.
thus, the user is not anywhere better satisfied than before.

The only thing that would work would be if dpkg and apt supported
Conflicts: korganizer (!= $binary:Version), but that is as far as I can
read in policy not valid, so I also don't expect the tools to support
it.

/Sune


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-05-2008, 01:39 AM
"Paul Wise"
 
Default Possibly excessive lintian warnings (was: NEW processing)

The best solution would just be to drop most -dbg packages, drop
maintainer-uploaded binary packages (using the buildd built packages
instead), install the dh_strip from debug.d.n on all the buildds and
get people to use -dbgsym packages from debug.d.n.

--
bye,
pabs

http://wiki.debian.org/PaulWise


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-05-2008, 02:19 AM
Raphael Geissert
 
Default Possibly excessive lintian warnings (was: NEW processing)

Paul Wise wrote:

> The best solution would just be to drop most -dbg packages, drop
> maintainer-uploaded binary packages (using the buildd built packages
> instead), install the dh_strip from debug.d.n on all the buildds and
> get people to use -dbgsym packages from debug.d.n.
>

a) That doesn't solve the dependencies problem.

b) There are lots of packages missing at debug.d.n, and they only keep one
package version. It isn't a drop-in replacement.

c) What's the point on using a separate server when we have mirrors?

d) We don't need debug symbols for every package out there.

Cheers,
Raphael Geissert


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 10:21 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org