Bug#626476: lintian: reduce dpkg-dev to Suggests

2011-05-20 Thread Russ Allbery 
Niels Thykier ni...@thykier.net writes:
 On 2011-05-17 19:49, Russ Allbery wrote:

 The choice of whether to explicitly state the Recommends should be
 based on whether Lintian ever invokes programs in it directly or via
 flags to tar or whether it only invokes it indirectly via libdpkg-perl.
 IIRC, we invoke it directly via a flag to tar.

 We use it in unpack/unpack-srcpkg-l1 to pass --lzma or --xz to tar.
 Other than that, I do not think we use it.  Do you want a
 suggests/recommends for this?

We should probably go with either Suggests or Recommends, then, since we
do invoke it essentially directly.

I think it's okay to leave it as Suggests for right now, at least until xz
is used by more of the archive.

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



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sjs9no9z@windlord.stanford.edu

Bug#626476: lintian: reduce dpkg-dev to Suggests

2011-05-17 Thread Colin Watson 
On Sat, May 14, 2011 at 07:50:45PM +0200, Niels Thykier wrote:
 On 2011-05-13 11:19, Niels Thykier wrote:
  I had a short chat with Raphaël Hertzog (buxy) in #debian-qa about this
  and he said that the unpacking part of the module was rather stable and
  it's certainly ok as a fallback when dpkg-source is not there.
  
  So as long as we only need dpkg-source -x (and not dpkg-source -b) we
  can use libdpkg-perl.
 
 Functional proof-of-concept patch; simply apply and profit!  The code is
 stolen from dpkg-source and cooked down a bit (... a lot).
 
 The patch here disables dpkg-source unpacking all together (saves you
 from peeling out dpkg-dev from a system).

That's a bit further than what Raphaël said this API was OK for - not
just a fallback when dpkg-source is not there.  Have you
double-checked that with him?

 The patch does not account for updating the Lintian Depends; I suspect
 that dpkg-dev should be replaced with bzip2, xz-utils and
 libdpkg-perl.  The former two can be most likely be left out if you
 know there are no bz2 / xz / lmza sources.

Or perhaps we can just rely on libdpkg-perl's Recommends of bzip2 and
xz-utils?

 I had to redirect STDOUT of unpacked to keeping it the unpack process
 quiet (otherwise it would break the output format of Lintian)[1].

You're right that Dpkg::ErrorHandling::report_options isn't marked as
stable, but shouldn't we at least be using options = { quiet = 1 } as
an argument to Dpkg::Source::Package-new as well as this, to match
dpkg-source -q?  It doesn't do much right now, but in principle it seems
as though it might avoid noise on stderr.

 +libdpkg_unpack_dsc ('dsc', 'unpacked');

Style nit: no space before the open parenthesis.

 +sub libdpkg_unpack_dsc {
 +my ($dsc, $target) = @_;
 +require Dpkg::Source::Package;
 +open(STDOUT, '', '/dev/null') or fail Redirecting stdout failed: $!;
 +# Create the object that does everything
 +my $srcpkg = Dpkg::Source::Package-new(filename = $dsc);
 +
 +$srcpkg-check_checksums();
 +
 +# Unpack the source package (delegated to Dpkg::Source::Package::*)
 +$srcpkg-extract($target);
 +return 1;
 +}

This drops the signature check currently performed by dpkg-source, so it
changes Lintian's behaviour to (a) accept .dsc files with bad signatures
and (b) stop issuing a warning for unsigned .dsc files.  This seems
undesirable.

Aside from that, the patch does seem to work as advertised.  Thanks!

-- 
Colin Watson   [cjwat...@ubuntu.com]



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110517161636.gp23...@riva.ucam.org

Bug#626476: lintian: reduce dpkg-dev to Suggests

2011-05-17 Thread Colin Watson 
On Tue, May 17, 2011 at 07:05:17PM +0200, Niels Thykier wrote:
 On 2011-05-17 18:16, Colin Watson wrote:
  On Sat, May 14, 2011 at 07:50:45PM +0200, Niels Thykier wrote:
  Functional proof-of-concept patch; simply apply and profit!  The code is
  stolen from dpkg-source and cooked down a bit (... a lot).
 
  The patch here disables dpkg-source unpacking all together (saves you
  from peeling out dpkg-dev from a system).
  
  That's a bit further than what Raphaël said this API was OK for - not
  just a fallback when dpkg-source is not there.  Have you
  double-checked that with him?
 
 It was not my intention to apply this patch as is.  The argument for
 disabling the dpkg-source usage was to ease your job as a tester (so you
 did not have to uninstall dpkg-dev from your machines).

Ah, OK.  FWIW I was just temporarily moving /usr/bin/dpkg-source aside
in my earlier tests rather than trying to uninstall the package.

  The patch does not account for updating the Lintian Depends; I suspect
  that dpkg-dev should be replaced with bzip2, xz-utils and
  libdpkg-perl.  The former two can be most likely be left out if you
  know there are no bz2 / xz / lmza sources.
  
  Or perhaps we can just rely on libdpkg-perl's Recommends of bzip2 and
  xz-utils?
 
 Possibly, I hope some of the other Lintian maintainers have a comment on
 this.  Should we just go with Depends: dpkg-dev | libdpkg-perl or do we
 want ...
 
 Recommends: dpkg-dev
 Depends/Recommends: bzip2, xz-utils

Neither of those would help my use case, because it would have the
effect of dragging dpkg-dev into our CD images anyway (we install
Recommends by default just as Debian does, and our tools prefer the
first element in a dependency disjunction if it exists).

How about:

  Depends: libdpkg-perl, bzip2, xz-utils
  Suggests: dpkg-dev

or:

  Depends: libdpkg-perl
  [Recommends: bzip2, xz-utils]
  Suggests: dpkg-dev

(Recommends in brackets because libdpkg-perl already recommends those,
so I'm not sure if there's much point in lintian repeating this.)

  This drops the signature check currently performed by dpkg-source, so it
  changes Lintian's behaviour to (a) accept .dsc files with bad signatures
  and (b) stop issuing a warning for unsigned .dsc files.  This seems
  undesirable.
  
  Aside from that, the patch does seem to work as advertised.  Thanks!
 
 Actually as far as I can tell, we do not get any warnings on unsigned
 source packages (possibly due to the -q option), but sure, checking
 signatures should not be an issue either.

Oh, you're right, -q would suppress the warning for unsigned files.  I
think my point (a) is still true though.

Thanks,

-- 
Colin Watson   [cjwat...@ubuntu.com]



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110517172655.gr23...@riva.ucam.org

Bug#626476: lintian: reduce dpkg-dev to Suggests

2011-05-17 Thread Niels Thykier 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2011-05-17 18:16, Colin Watson wrote:
 On Sat, May 14, 2011 at 07:50:45PM +0200, Niels Thykier wrote:
 On 2011-05-13 11:19, Niels Thykier wrote:
 I had a short chat with Raphaël Hertzog (buxy) in #debian-qa about this
 and he said that the unpacking part of the module was rather stable and
 it's certainly ok as a fallback when dpkg-source is not there.

 So as long as we only need dpkg-source -x (and not dpkg-source -b) we
 can use libdpkg-perl.

 Functional proof-of-concept patch; simply apply and profit!  The code is
 stolen from dpkg-source and cooked down a bit (... a lot).

 The patch here disables dpkg-source unpacking all together (saves you
 from peeling out dpkg-dev from a system).
 
 That's a bit further than what Raphaël said this API was OK for - not
 just a fallback when dpkg-source is not there.  Have you
 double-checked that with him?
 

It was not my intention to apply this patch as is.  The argument for
disabling the dpkg-source usage was to ease your job as a tester (so you
did not have to uninstall dpkg-dev from your machines).

 The patch does not account for updating the Lintian Depends; I suspect
 that dpkg-dev should be replaced with bzip2, xz-utils and
 libdpkg-perl.  The former two can be most likely be left out if you
 know there are no bz2 / xz / lmza sources.
 
 Or perhaps we can just rely on libdpkg-perl's Recommends of bzip2 and
 xz-utils?
 

Possibly, I hope some of the other Lintian maintainers have a comment on
this.  Should we just go with Depends: dpkg-dev | libdpkg-perl or do we
want ...

Recommends: dpkg-dev
Depends/Recommends: bzip2, xz-utils

?

 I had to redirect STDOUT of unpacked to keeping it the unpack process
 quiet (otherwise it would break the output format of Lintian)[1].
 
 You're right that Dpkg::ErrorHandling::report_options isn't marked as
 stable, but shouldn't we at least be using options = { quiet = 1 } as
 an argument to Dpkg::Source::Package-new as well as this, to match
 dpkg-source -q?  It doesn't do much right now, but in principle it seems
 as though it might avoid noise on stderr.


Sure, I can add that.


 +libdpkg_unpack_dsc ('dsc', 'unpacked');
 
 Style nit: no space before the open parenthesis.
 

Right...

 +sub libdpkg_unpack_dsc {
 +my ($dsc, $target) = @_;
 +require Dpkg::Source::Package;
 +open(STDOUT, '', '/dev/null') or fail Redirecting stdout failed: $!;
 +# Create the object that does everything
 +my $srcpkg = Dpkg::Source::Package-new(filename = $dsc);
 +
 +$srcpkg-check_checksums();
 +
 +# Unpack the source package (delegated to Dpkg::Source::Package::*)
 +$srcpkg-extract($target);
 +return 1;
 +}
 
 This drops the signature check currently performed by dpkg-source, so it
 changes Lintian's behaviour to (a) accept .dsc files with bad signatures
 and (b) stop issuing a warning for unsigned .dsc files.  This seems
 undesirable.
 
 Aside from that, the patch does seem to work as advertised.  Thanks!
 

Actually as far as I can tell, we do not get any warnings on unsigned
source packages (possibly due to the -q option), but sure, checking
signatures should not be an issue either.

~Niels

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJN0qrIAAoJEAVLu599gGRCKnwP/09LXM1Ot3G5UGuWXaEESuvO
kfH3/Q7OoGz5oqa3DqkcYcIlyD1cdDwD1f7aJKbVaTtlNa7obwMRNBoO48uDX0Zn
Y205vlnZXUUubyjCrl5c8/JJEoLktRIsZgBMSPBmcOrpEDMunWS64CZbj2B/MZzk
BTzrZrcc/DdvVvuNNbbwM4KNzHUN4l23njsnHI8sTPcpSHQ8xYT5EUxXU0IftEkP
32SSOgQarG4ijRZqDqZWiGuidIhEl5lgLlbN+5ag8ElIcVnAgPZ+LOpPPTDgfsWW
COVOKeKlyZs3qUn5tYS8vOlc3bNnjmhT/g+OgnNdWdLq5iU+LonZFKwYWhRWnOz6
hjC3YaB4MziRYxcjeIZYWxM8vYy/k/QnA7vevip/bQ36UMHTY9dpEvFfVN2RRydl
4RugmVSNGlfkIc0nHT0RCTVfTzQsWpjYRwH/DbIlv4TDg6qkqbZJjmVH4717t1ik
UBtJg842Q5CrMWqCx+6mQ4AZDMhvjZABmzESOpj3vleHRn/RlGANfn5kEZjNlrhN
VhPgO0awx+Rs55mF4Lcb4t8cH089s90enQkCmZklOI1MXlMsnhQol30Ru+rZsjPl
Ipbt0/y6kXtHjxMoRzj6LHq5lUtSsFDuaVod6h8Z81cUEij4cNcwPMXoOamxEfom
Uflp27Q8cRRJ5tYUEJ5N
=I+qh
-END PGP SIGNATURE-



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dd2aacd.9040...@thykier.net

Bug#626476: lintian: reduce dpkg-dev to Suggests

2011-05-17 Thread Russ Allbery 
Colin Watson cjwat...@ubuntu.com writes:

 Neither of those would help my use case, because it would have the
 effect of dragging dpkg-dev into our CD images anyway (we install
 Recommends by default just as Debian does, and our tools prefer the
 first element in a dependency disjunction if it exists).

 How about:

   Depends: libdpkg-perl, bzip2, xz-utils
   Suggests: dpkg-dev

 or:

   Depends: libdpkg-perl
   [Recommends: bzip2, xz-utils]
   Suggests: dpkg-dev

 (Recommends in brackets because libdpkg-perl already recommends those,
 so I'm not sure if there's much point in lintian repeating this.)

Yeah, one of these look right to me.

Given the number of packages in the archive that use bzip2 compression and
the small size of the bzip2 package, I'd prefer to have it as a strong
dependency.  I don't have a similar opinion about xz-utils, since I don't
have the impression that it's much used yet, so I'd be okay with leaving
that as Recommends.

The choice of whether to explicitly state the Recommends should be based
on whether Lintian ever invokes programs in it directly or via flags to
tar or whether it only invokes it indirectly via libdpkg-perl.  IIRC, we
invoke it directly via a flag to tar.

 Oh, you're right, -q would suppress the warning for unsigned files.  I
 think my point (a) is still true though.

Yeah, we suppress warnings for unsigned source packages since it's very
common to check a source package with Lintian in advance of signing it.

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



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877h9p43pp@windlord.stanford.edu

Bug#626476: lintian: reduce dpkg-dev to Suggests

2011-05-14 Thread Niels Thykier 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2011-05-13 11:19, Niels Thykier wrote:
 On 2011-05-13 00:06, Colin Watson wrote:
 [...]
 
 I had a short chat with Raphaël Hertzog (buxy) in #debian-qa about this
 and he said that the unpacking part of the module was rather stable and
 it's certainly ok as a fallback when dpkg-source is not there.
 
 So as long as we only need dpkg-source -x (and not dpkg-source -b) we
 can use libdpkg-perl.
 
 ~Niels
 
 [...]
 

Functional proof-of-concept patch; simply apply and profit!  The code is
stolen from dpkg-source and cooked down a bit (... a lot).

The patch here disables dpkg-source unpacking all together (saves you
from peeling out dpkg-dev from a system).  The patch does not account
for updating the Lintian Depends; I suspect that dpkg-dev should be
replaced with bzip2, xz-utils and libdpkg-perl.  The former two can be
most likely be left out if you know there are no bz2 / xz / lmza sources.

I had to redirect STDOUT of unpacked to keeping it the unpack process
quiet (otherwise it would break the output format of Lintian)[1].

~Niels

[1] Technically there was an API to do it from within libdpkg-perl, but
it was not declared stable, so I went with a redirect instead.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJNzsDxAAoJEAVLu599gGRCb6UP/1Vzcdf5ddiyNNVEm+fe2PA8
5trbrJj5CgaCc4+MrmxLxZcHuazaX6A7mpWQ0NokxzGy2r8MmRztv7QQ/GY14m+1
bidbsHIRixwLeHeHB8TDVs1G2aSNke+kWkCP6r8fex7uXi7L8njIiy6epntb9f4a
s70DFwNg0kzXLzrbLah3Cxo/6TNTqXXUEHI8d2mXWVLFeICvJW+wNI2pqjk25Qsg
DpZTmZ3HS719Y66Ta3aVky8KBjGPRQUrqA9bxDu9A95yYgnm7xrSmwOoK6ucpCci
sS1um+lFLOJ95hnpiQJ0BhuplloK+64ja+Lgo01F8N1bg9eKv6vi6421zLBXjJDq
Y2ShnedHnkMn0YURYFEipbs80Fn68jlq8MjaltNiUmYIldiSt74H+IrUXvBRm4ox
BcD+QdwWgl7PUpYi4uYqqkAqp+IXXhJteYrsQM5ZkmIWgVwTmSFrqSr9xJD0ucTr
PSEkXycnfwaDUd6ft57ecrzuN25qpL6mPUch6f1HG8MnB2BXwNqTfVCz9Tau4/Nj
3+9EXFoVuD5axdMSaOQcLRumLIhTDri+B23bTpngUMDFnfj+2mKvvtf3af/+SQuU
wUAhnBH37sPDErjKnnGhpV4BBHF3spdHjL/8Mv869wlc4XN2ViyigBO2LGuNKcah
XhBsmp6qiIQ1RjnUNSeV
=HXyf
-END PGP SIGNATURE-
From 5e17cad62d101b6795c7230a7b257201d489787b Mon Sep 17 00:00:00 2001
From: Niels Thykier ni...@thykier.net
Date: Sat, 14 May 2011 19:37:26 +0200
Subject: [PATCH] Sample patch to unpack using libdpkg-perl instead
 dpkg-source

---
 collection/unpacked |   36 
 1 files changed, 28 insertions(+), 8 deletions(-)

diff --git a/collection/unpacked b/collection/unpacked
index 1cceb5a..a98a65c 100755
--- a/collection/unpacked
+++ b/collection/unpacked
@@ -48,18 +48,25 @@ if ($type =~ m/^remove-/) {
 if ($type eq 'source') {
 # Ignore STDOUT of the child process because older versions of
 # dpkg-source print things out even with -q.
-my $opts = { out = '/dev/null', err = 'unpacked-errors' };
-unless (spawn($opts, ['dpkg-source', '-q', '-x', 'dsc', 'unpacked'])) {
-	open(ERRORS, '', 'unpacked-errors')
-	or fail(cannot open unpacked-errors: $!);
-	print STDERR while ERRORS;
-	close ERRORS;
-	fail('dpkg-source -x failed with status ', $opts-{harness}-result);
+if (0) {
+my $opts = { out = '/dev/null', err = 'unpacked-errors' };
+unless (spawn($opts, ['dpkg-source', '-q', '-x', 'dsc', 'unpacked'])) {
+open(ERRORS, '', 'unpacked-errors')
+or fail(cannot open unpacked-errors: $!);
+print STDERR while ERRORS;
+close ERRORS;
+fail('dpkg-source -x failed with status ', $opts-{harness}-result);
+}
+
+
+} else {
+print STDERR N: Using libdpkg-perl.\n;
+libdpkg_unpack_dsc ('dsc', 'unpacked');
 }
 
 # fix permissions
 spawn({ fail = 'error' },
-	  ['chmod', '-R', 'u+rwX,o+rX,o-w', 'unpacked']);
+  ['chmod', '-R', 'u+rwX,o+rX,o-w', 'unpacked']);
 
 } else {
 mkdir('unpacked', 0777) or fail(mkdir unpacked: $!);
@@ -85,3 +92,16 @@ if ($type eq 'source') {
 	['chmod', '-R', 'u+rwX,go-w', 'unpacked']);
 }
 
+sub libdpkg_unpack_dsc {
+my ($dsc, $target) = @_;
+require Dpkg::Source::Package;
+open(STDOUT, '', '/dev/null') or fail Redirecting stdout failed: $!;
+# Create the object that does everything
+my $srcpkg = Dpkg::Source::Package-new(filename = $dsc);
+
+$srcpkg-check_checksums();
+
+# Unpack the source package (delegated to Dpkg::Source::Package::*)
+$srcpkg-extract($target);
+return 1;
+}
-- 
1.7.4.4



0001-Sample-patch-to-unpack-using-libdpkg-perl-instead-dp.patch.sig
Description: Binary data

Bug#626476: lintian: reduce dpkg-dev to Suggests

2011-05-13 Thread Niels Thykier 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2011-05-13 00:06, Colin Watson wrote:
 On Thu, May 12, 2011 at 11:45:03PM +0200, Niels Thykier wrote:
 On 2011-05-12 23:00, Colin Watson wrote:
 Hmm.  I kicked this around with some of my team.  Here are a few
 alternatives, all a bit grotty in one way or another:

  * Split lintian into two binary packages, one of which only supports
checking binary packages, and the other of which (still called
'lintian') supports everything and depends on the first.

  * Reimplement the small number of checks we consider for this use case
in aptdaemon or somewhere else.

  * Split out dpkg-source from dpkg-dev.

 An alternative to this is to use libdpkg-perl to do the unpacking; that
 would save some depends of dpkg-dev, assuming the libdpkg-perl API is
 stable here.
 
 While I agree that this is a further interesting alternative over and
 above those I listed, /usr/share/doc/libdpkg-perl/README.api says:
 
 What: libdpkg-perl (perl modules)
 Status: stable
 Description:
  Among the perl modules provided by libdpkg-perl, you can safely rely on
  those that have $VERSION set to 1.00 (or higher). Note however that the
  API is defined by what's documented in the corresponding manual pages and
  nothing more. You can't assume anything else based on what you read in
  the source code. If you feel the need for further refinements in the
  documented API, don't hesitate to file a wishlist bug against
  libdpkg-perl.
  .
  In case of API-breaking changes, the major number in $VERSION will be
  increased. For API extensions, the minor number will be increased.
 
 The necessary module is /usr/share/perl5/Dpkg/Source/Package.pm, which
 has $VERSION set to 0.01 and has no manual page, so according to the
 documentation we are not allowed to rely on that being stable yet.
 

I had a short chat with Raphaël Hertzog (buxy) in #debian-qa about this
and he said that the unpacking part of the module was rather stable and
it's certainly ok as a fallback when dpkg-source is not there.

So as long as we only need dpkg-source -x (and not dpkg-source -b) we
can use libdpkg-perl.

~Niels

For reference, the entire chat:
(11:01:53) nthykier: buxy: Hey, how stable is the API behind
libdpkg-perl Dpkg::Source::Package?  I understand it is not officially
stable, but how far away is it from being stable?
(11:02:18) nthykier: The context being #626476
(11:11:45) buxy: nthykier: quite far in general, as dpkg-source does
much things that are not done in the perl modules, but the part that
deals with unpacking is rather stable, it's certainly ok as a fallback
when dpkg-source is not there
(11:12:11) buxy: (i.e. my first remark applies mainly to dpkg-source -b
and not dpkg-source -x)
(11:12:51) nthykier: Thanks, I will try to setup Lintian with a
libdpkg-perl fall-back then

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJNzPeEAAoJEAVLu599gGRCE2YQAJLmuGQTGqaNkMZMLHjrO2lN
vod25s54Nz/iwnW/KN2gzTR4BlTbVjhYHQGZK3tA0QJR0PfJmTD6tPTmTFzv7TI/
ZhH68x2h+ZcfncnQa9vWZBsw+A3egM0/UULhBzs03cQRTXu49OK2wxB/N2Dg9Zqc
enAskxsVPeZmUtazfzAo6DV2GtH9k4EfbAMIqGJccIR8JjvK8+Z8CxFst1sqWtjH
7GkFm1+hJW8i5MmU68PbdX8BGRN2YRaRGrmDj+zNtmCS1O9aiCUB1mdALd5KJm9+
p7VsDboqDUuEsPuDYE+BDrwwQYxSNAOApU4k0I/+y171JC5PIhDUpCfxQNDBuSe7
Yfek0SMqm+Ey/9paMMeBlV06XnFditUwXSRZLPwzsP+XQ5Aw/gJPLVtAWDxqKWBc
nEvkYQCvvRMDnu90sps3yuvpy1NJ2/MhU5G2qNTbBmyzvZaMY5ck0JA1uSrbciMl
zcBP695XIG3jhldUgGfbPjDP62uUuioYIP9hfVRy6UyfyCsJ3Auw7JyTfNL625ey
r2lxMqUv6ZJOuMB3qQta5Hvgi+E4MipBJWw7T4svlx709/KNleSzZdZdcRs6yxLY
duHG9El384S6rkAjM2mIMBm34jNP1HXYYKSzTFUfVSqH19WEAvgrtMXg9q+eeJmD
EJvxWDxaspFCPqbV5VGN
=KPwT
-END PGP SIGNATURE-



--
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dccf784@thykier.net

Bug#626476: lintian: reduce dpkg-dev to Suggests

2011-05-12 Thread Colin Watson 
Package: lintian
Version: 2.5.0~rc3
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch oneiric

We're shipping lintian on Ubuntu CD images as a Recommends of aptdaemon,
in order to do some basic sanity checks on third-party binary packages.
Unfortunately this pulls in dpkg-dev and its dependencies, which are
rather heavyweight.  Some analysis shows that the only thing that we
need dpkg-dev for is to unpack source packages, so it's possible to
check binary packages without dpkg-dev.

The attached patch checks whether dpkg-source is available and produces
a better error message; it then drops dpkg-dev to a Suggests so that we
don't have to ship it.  I don't think this should particularly
negatively affect anyone - if you're building packages, you have
dpkg-dev installed anyway, and probably not solely by means of
installing lintian - but I thought I'd file a bug about it rather than
just committing it so that we could discuss it in case anyone had any
objections.

diff --git a/collection/unpacked b/collection/unpacked
index 1cceb5a..7688711 100755
--- a/collection/unpacked
+++ b/collection/unpacked
@@ -24,7 +24,7 @@ use strict;
 use warnings;
 
 use lib $ENV{'LINTIAN_ROOT'}/lib;
-use Lintian::Command qw(spawn);
+use Lintian::Command qw(spawn on_path);
 use Util;
 
 ($#ARGV == 1) or fail('syntax: unpacked package type');
@@ -46,6 +46,10 @@ if ($type =~ m/^remove-/) {
 }
 
 if ($type eq 'source') {
+unless (on_path('dpkg-source')) {
+   fail('dpkg-source missing - is the dpkg-dev package installed?');
+}
+
 # Ignore STDOUT of the child process because older versions of
 # dpkg-source print things out even with -q.
 my $opts = { out = '/dev/null', err = 'unpacked-errors' };
diff --git a/debian/control b/debian/control
index 93e75bf..70cd345 100644
--- a/debian/control
+++ b/debian/control
@@ -55,7 +55,6 @@ Package: lintian
 Architecture: all
 Depends: binutils,
  diffstat,
- dpkg-dev,
  file,
  gettext,
  intltool-debian,
@@ -73,6 +72,7 @@ Depends: binutils,
  unzip,
  ${misc:Depends}
 Suggests: binutils-multiarch,
+  dpkg-dev,
   libhtml-parser-perl,
   libtext-template-perl,
   man-db (= 2.5.1-1)
diff --git a/lib/Lintian/Command.pm b/lib/Lintian/Command.pm
index 5317a9b..2994cc0 100644
--- a/lib/Lintian/Command.pm
+++ b/lib/Lintian/Command.pm
@@ -27,7 +27,7 @@ BEGIN {
 
 use base qw(Exporter);
 our @EXPORT = ();
-our @EXPORT_OK = qw(spawn reap kill);
+our @EXPORT_OK = qw(spawn reap kill on_path);
 
 use IPC::Run qw(run harness kill_kill);
 
@@ -333,13 +333,30 @@ sub done {
 }
 }
 
+=head2 Con_path($command)
+
+Return true if and only if $command is on the executable search path.
+
+=cut
+
+sub on_path {
+my $command = shift;
+
+return 0 unless exists $ENV{PATH};
+for my $element (split ':', $ENV{PATH}) {
+   next unless length $element;
+   return 1 if -f $element/$command and -x _;
+}
+return 0;
+}
+
 1;
 __END__
 
 =head1 EXPORTS
 
 Lintian::Command exports nothing by default, but you can export the
-spawn() and reap() functions.
+spawn(), reap(), kill(), and on_path() functions.
 
 =head1 AUTHOR
 

Thanks,

-- 
Colin Watson   [cjwat...@ubuntu.com]



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110512094548.gy23...@riva.ucam.org

Bug#626476: lintian: reduce dpkg-dev to Suggests

2011-05-12 Thread Russ Allbery 
Colin Watson cjwat...@ubuntu.com writes:

 We're shipping lintian on Ubuntu CD images as a Recommends of aptdaemon,
 in order to do some basic sanity checks on third-party binary packages.
 Unfortunately this pulls in dpkg-dev and its dependencies, which are
 rather heavyweight.  Some analysis shows that the only thing that we
 need dpkg-dev for is to unpack source packages, so it's possible to
 check binary packages without dpkg-dev.

 The attached patch checks whether dpkg-source is available and produces
 a better error message; it then drops dpkg-dev to a Suggests so that we
 don't have to ship it.  I don't think this should particularly
 negatively affect anyone - if you're building packages, you have
 dpkg-dev installed anyway, and probably not solely by means of
 installing lintian - but I thought I'd file a bug about it rather than
 just committing it so that we could discuss it in case anyone had any
 objections.

Hurm.  I have to admit that this doesn't make me particularly happy, since
checking source packages seems like a fundamental action of Lintian.  The
use of dpkg-dev in Lintian seems to meet the Policy definition of at
*least* Recommends fairly clearly, and Suggests feels much too weak when
we lose that basic of functionality.

On the other hand, I have no alternative solution to your particular
problem; the Recommends list of dpkg-dev is indeed rather heavy, since it
includes build-essential.

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



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87hb8z533r@windlord.stanford.edu

Bug#626476: lintian: reduce dpkg-dev to Suggests

2011-05-12 Thread Colin Watson 
On Thu, May 12, 2011 at 08:51:36AM -0700, Russ Allbery wrote:
 Hurm.  I have to admit that this doesn't make me particularly happy, since
 checking source packages seems like a fundamental action of Lintian.  The
 use of dpkg-dev in Lintian seems to meet the Policy definition of at
 *least* Recommends fairly clearly, and Suggests feels much too weak when
 we lose that basic of functionality.
 
 On the other hand, I have no alternative solution to your particular
 problem; the Recommends list of dpkg-dev is indeed rather heavy, since it
 includes build-essential.

Hmm.  I kicked this around with some of my team.  Here are a few
alternatives, all a bit grotty in one way or another:

 * Split lintian into two binary packages, one of which only supports
   checking binary packages, and the other of which (still called
   'lintian') supports everything and depends on the first.

 * Reimplement the small number of checks we consider for this use case
   in aptdaemon or somewhere else.

 * Split out dpkg-source from dpkg-dev.

 * Observe that we already document how to unpack source packages
   without dpkg-dev for users of non-Debian systems (in
   /usr/share/doc/debian/source-unpack.txt - it currently only documents
   format 1.0, but I attached a patch to #579263 some time ago that
   updates this to 3.0), and that therefore this is an interface that
   it's not necessarily too dreadful to reimplement as long as it's
   strictly as a fallback for the case where dpkg-source is not present.

Perhaps oddly, I think the last of those actually strikes me as the
least bad solution, although only because the method is already
documented (modulo that bug report).

-- 
Colin Watson   [cjwat...@ubuntu.com]



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110512210047.ga23...@riva.ucam.org

Bug#626476: lintian: reduce dpkg-dev to Suggests

2011-05-12 Thread Niels Thykier 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 2011-05-12 23:00, Colin Watson wrote:
 On Thu, May 12, 2011 at 08:51:36AM -0700, Russ Allbery wrote:
 Hurm.  I have to admit that this doesn't make me particularly happy, since
 checking source packages seems like a fundamental action of Lintian.  The
 use of dpkg-dev in Lintian seems to meet the Policy definition of at
 *least* Recommends fairly clearly, and Suggests feels much too weak when
 we lose that basic of functionality.

 On the other hand, I have no alternative solution to your particular
 problem; the Recommends list of dpkg-dev is indeed rather heavy, since it
 includes build-essential.
 

Hi

 Hmm.  I kicked this around with some of my team.  Here are a few
 alternatives, all a bit grotty in one way or another:
 
  * Split lintian into two binary packages, one of which only supports
checking binary packages, and the other of which (still called
'lintian') supports everything and depends on the first.
 
  * Reimplement the small number of checks we consider for this use case
in aptdaemon or somewhere else.
 
  * Split out dpkg-source from dpkg-dev.
 

An alternative to this is to use libdpkg-perl to do the unpacking; that
would save some depends of dpkg-dev, assuming the libdpkg-perl API is
stable here.

  * Observe that we already document how to unpack source packages
without dpkg-dev for users of non-Debian systems (in
/usr/share/doc/debian/source-unpack.txt - it currently only documents
format 1.0, but I attached a patch to #579263 some time ago that
updates this to 3.0), and that therefore this is an interface that
it's not necessarily too dreadful to reimplement as long as it's
strictly as a fallback for the case where dpkg-source is not present.
 
 Perhaps oddly, I think the last of those actually strikes me as the
 least bad solution, although only because the method is already
 documented (modulo that bug report).
 

~Niels

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJNzFTcAAoJEAVLu599gGRC03AP/2MF6WRnFd3ly81Ov09A8mPS
upDy++pwXnl1kx4Nt7gi22VQnr42M3QrOiBoAF5aMbfrxfbGirTUUZyidx93WivF
iTUcw7xvqxBNxWeSklde89RnpU70VnBq8kxe5luGftoSLbVCljhNlalL6Vp78RxI
c6MKbHPmBUPDMjzcCzOxutJfMUfw8uGj+gSO3qVNK0a0yn0ixeTluV5Qt2TusMNM
DGDRUq3I+vJ6e2AtVuN1hSPlNMvycIR9clfO1znXJ7vSPMbBJ+A1todXfP6wiDPn
YwhlnkU5Torj78mNzNxwcYU6ZIJTIl0gehwH+h1Tbz6jYDpbkycr44MNAf4hhwUy
oow2N1GucG7DpYEs1ZpUd+2TcXtJ7DpUT9Zua04XQnDK2voStd6YJNye2M6btEbp
SkNYEurFZirvTFhFd3LhBlNrqQFBiKIwxcBoJlKpmyce3QBI81DsX+Bq+egnL0xN
YDi8wDoBrg8Aj6HN7iuEj31a/gmbFnW/cBt9IpK8oWyRIkhgND1TsvR1+yc82EKa
/DboxEJ/2yutXvvkaHZhfFEjKk3q5+NMSvm7bOvE3AX7tcT6eKhFUPOQoQmJ+Bis
N8xPIZsD5smNIMg3FO8eDs1AfiSdaSt92ADdcP01K0b9USZjU6DSIsPtfCQIu+EX
8Tf3TzbhYJMXPhUsCNHJ
=SYF0
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4dcc54df.2050...@thykier.net

Bug#626476: lintian: reduce dpkg-dev to Suggests

2011-05-12 Thread Russ Allbery 
Colin Watson cjwat...@ubuntu.com writes:

 Hmm.  I kicked this around with some of my team.  Here are a few
 alternatives, all a bit grotty in one way or another:

  * Split lintian into two binary packages, one of which only supports
checking binary packages, and the other of which (still called
'lintian') supports everything and depends on the first.

This is architecturally tricky, I think, although I've not looked at it in
detail.

  * Reimplement the small number of checks we consider for this use case
in aptdaemon or somewhere else.

I would really like to enable you to use Lintian.  This is exactly the
kind of thing that I'd like to see it be usable for, and the more
different ways we use it, the more resources and bug fixes we get to make
it better for everyone.

  * Split out dpkg-source from dpkg-dev.

Obviously, this is the simplest solution from the Lintian perspective, but
I doubt the dpkg folks would be particularly thrilled by that additional
complexity for an unusual case.  I'm not sure, though.

  * Observe that we already document how to unpack source packages
without dpkg-dev for users of non-Debian systems (in
/usr/share/doc/debian/source-unpack.txt - it currently only documents
format 1.0, but I attached a patch to #579263 some time ago that
updates this to 3.0), and that therefore this is an interface that
it's not necessarily too dreadful to reimplement as long as it's
strictly as a fallback for the case where dpkg-source is not present.

We could do this.  My main concern here is that our fallback
implementation will be work to maintain if there are further changes to
the source format (3.0 git, for example), and may have interesting bugs
that are different from those in dpkg-source.  (There are security issues
around this unpacking, for instance.)  But if we only do it as a fallback,
and it came with some tests, this isn't too bad of a solution.

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



-- 
To UNSUBSCRIBE, email to debian-lint-maint-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877h9v1svt@windlord.stanford.edu