Debian Bug report logs - #661538
Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops

version graph

Package: dpkg-dev; Maintainer for dpkg-dev is Dpkg Developers <debian-dpkg@lists.debian.org>; Source for dpkg-dev is src:dpkg.

Reported by: Wookey <wookey@debian.org>

Date: Mon, 27 Feb 2012 21:39:05 UTC

Severity: wishlist

Fixed in version dpkg/1.17.2

Done: Guillem Jover <guillem@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg. (Mon, 27 Feb 2012 21:39:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wookey <wookey@debian.org>:
New Bug report received and forwarded. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 27 Feb 2012 21:39:10 GMT) Full text and rfc822 format available.

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

From: Wookey <wookey@debian.org>
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Mon, 27 Feb 2012 19:17:48 +0000
[Message part 1 (text/plain, inline)]
Package: dpkg
Version: 1.16.1.2
Severity: wishlist
Tags: patch

Cyclic build-dependencies are a big problem in Debian, which make new
ports very difficult, or rebuilds for other reasons such as hardware
optimisations.

The subject is covered in some detail here:
http://wiki.debian.org/DebianBootstrap
and was covered at Debconf in Baja Luka.

This little patch allows Build-Depends-Stage1 to be added to package
control files, for rules files to use DEB_BUILD_OPTIONS=STAGEN, and
for dpkg-checkbuilddeps to not complain about the missing
build-depends when doing staged/bootstrap builds.

I am very happy to change the implementation details if there are
reasons why this is not liked as-is - the details of the mechanism are
not important.

If we can get this support into Wheezy then it will be easy to do work
on this problem in packages over the next release cycle without needed
a patched dpkg, so I hope that's do-able. (Yes I know I should have
filed this patch 8 months ago when I wrote it).

-- System Information:
Debian Release: wheezy/sid
  APT prefers testing
  APT policy: (990, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dpkg depends on:
ii  coreutils    8.13-3
ii  libbz2-1.0   1.0.6-1
ii  libc6        2.13-26
ii  libselinux1  2.1.0-4.1
ii  xz-utils     5.1.1alpha+20110809-3
ii  zlib1g       1:1.2.6.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt  0.8.15.9

-- no debconf information
[dpkg-1.16.0.3-stage1.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg. (Tue, 28 Feb 2012 02:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 28 Feb 2012 02:33:03 GMT) Full text and rfc822 format available.

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

From: Jonathan Nieder <jrnieder@gmail.com>
To: Wookey <wookey@debian.org>
Cc: 661538@bugs.debian.org
Subject: Re: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Mon, 27 Feb 2012 20:29:19 -0600
Hi,

Wookey wrote:

> Cyclic build-dependencies are a big problem in Debian, which make new
> ports very difficult, or rebuilds for other reasons such as hardware
> optimisations.

Thanks very much for working on this.

I'll let others talk about any thorny design issues. :)  I just have
a couple of quick hints:

> --- dpkg-1.16.0.3.orig/scripts/Dpkg/Control/Fields.pm	2011-05-04 09:28:00.000000000 +0100
> +++ dpkg-1.16.0.3/scripts/Dpkg/Control/Fields.pm	2011-07-07 14:53:40.510189000 +0100
> @@ -73,10 +73,20 @@
>          dependency => 'normal',
>          dep_order => 1,
>      },
> +    'Build-Depends-Stage1' => {
> +        allowed => ALL_SRC,
> +        dependency => 'normal',
> +        dep_order => 1,

The dep_order values are all supposed to be distinct.  I am not
sure how important the particular order is --- Raphaël, what
would go wrong if we just used alphabetical order to avoid this
particular maintenance hassle?

[...]
> +++ dpkg-1.16.0.3/scripts/dpkg-buildpackage.pl	2011-07-06 02:23:11.439824001 +0100
> @@ -122,6 +122,7 @@
[...]
> +my $buildstage = 0;

Where does this get set to nonzero?

[...]
> --- dpkg-1.16.0.3.orig/scripts/dpkg-checkbuilddeps.pl	2011-05-04 09:28:01.000000000 +0100
> +++ dpkg-1.16.0.3/scripts/dpkg-checkbuilddeps.pl	2011-07-06 02:46:05.039824002 +0100
> @@ -49,6 +49,8 @@
>                   retrieving them from control file
>    --admindir=<directory>
>                   change the administrative directory.
> +  --stage=<level>
> +                 use build-depends-stage level specified

Would be nice to document this in the manpage, too.  See
http://bugs.debian.org/629480#35 for an example patch adding a
Build-Depends variant that covers its bases well.

A couple example tests, either in the form of simple commands I
can try that use equivs, or, even better, a patch against

  git://git.debian.org/dpkg/pkg-tests.git

would be nice for ironing out the behavior (and acting as a surrogate
user that will notice and complain if it gets broken in the future).

I wonder if in some cases the stage1 package is already useful and
deserves its own name, but please don't take such musings seriously
until I have stared at a demo and had a chance to work out the pieces
I am missing.

Sincerely,
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg. (Tue, 28 Feb 2012 07:57:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 28 Feb 2012 07:57:09 GMT) Full text and rfc822 format available.

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

From: Raphael Hertzog <hertzog@debian.org>
To: Wookey <wookey@debian.org>, 661538@bugs.debian.org
Subject: Re: Bug#661538: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Tue, 28 Feb 2012 08:53:14 +0100
On Mon, 27 Feb 2012, Wookey wrote:
> The subject is covered in some detail here:
> http://wiki.debian.org/DebianBootstrap
> and was covered at Debconf in Baja Luka.
> 
> This little patch allows Build-Depends-Stage1 to be added to package
> control files, for rules files to use DEB_BUILD_OPTIONS=STAGEN, and
> for dpkg-checkbuilddeps to not complain about the missing
> build-depends when doing staged/bootstrap builds.

Some remarks:

I don't like the fact the you have numbered fields and that you
only include "Stage1" as known field. If we keep this numbered field
approach, we have to implement something generic to recognize all the
indexed fields (Stage1, Stage2, etc.).

But in fact I wonder if we can't simply get rid of those fields and embed
everything in the usual field. When doing a staged build,
dpkg-checkbuilddeps could implicitly create a fake package
"bootstrap-stage" with a version corresponding to the requested stage.
When not doing a staged build, the version would be "99".

The you can say that some dependencies are to be discarded in staged
builds:
libldap-dev | bootstrap-stage (<< 99)

Or in some speficic staged build:
libldap-dev | bootstrap-stage (= 1)

Or you can add dependencies for a specific stage:
bootstrap-stage (!= 2) | foo-minimal

You can find the number of available stages by generating the simplified
build dep for successive stage numbers until the resulting dependencies
no longer changes.

The main disadvantage of this approach is that many other tools have to
learn to create this fake package when resolving this dependency (only
to support the case where you add a dependency to a specific stage, are
there any cases of this? the other cases are backwards compatible for
tools who are interested in normal build dependencies)

What do other people think of this? Had this been considered in your
discussions?

> If we can get this support into Wheezy then it will be easy to do work
> on this problem in packages over the next release cycle without needed
> a patched dpkg, so I hope that's do-able. (Yes I know I should have
> filed this patch 8 months ago when I wrote it).

It looks like doable if we can agree on what's the best approach.

> +my $buildstage = 0;

As Jonathan pointed out, you're lacking the option parsing code that sets
this variable. And also the corresponding manual page update.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Pre-order a copy of the Debian Administrator's Handbook and help
liberate it: http://debian-handbook.info/liberation/




Bug reassigned from package 'dpkg' to 'dpkg-dev'. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Tue, 03 Apr 2012 05:21:05 GMT) Full text and rfc822 format available.

No longer marked as found in versions dpkg/1.16.1.2. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Tue, 03 Apr 2012 05:21:06 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, alkmim@ic.unicamp.br, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Thu, 12 Apr 2012 18:15:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Gustavo Prado Alkmim <alkmim@ic.unicamp.br>:
Extra info received and forwarded to list. Copy sent to alkmim@ic.unicamp.br, Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 12 Apr 2012 18:15:03 GMT) Full text and rfc822 format available.

Message #24 received at 661538@bugs.debian.org (full text, mbox):

From: Gustavo Prado Alkmim <alkmim@ic.unicamp.br>
To: Debian Bug Tracking System <661538@bugs.debian.org>
Subject: Re: support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Thu, 12 Apr 2012 15:13:41 -0300
[Message part 1 (text/plain, inline)]
Package: dpkg
Severity: normal

Package: dpkg
Version: 1.16.2
Severity: wishlist
Tags: patch

Patch updated to work on dpkg-1.16.2.

-- System Information:
Debian Release: 6.0.4
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages dpkg depends on:
ii  coreutils               8.5-1            GNU core utilities
ii  libbz2-1.0              1.0.5-6+squeeze1 high-quality block-sorting file co
ii  libc6                   2.11.3-3         Embedded GNU C Library: Shared lib
ii  libselinux1             2.0.96-1         SELinux runtime shared libraries
ii  xz-utils                5.0.0-2          XZ-format compression utilities
ii  zlib1g                  1:1.2.3.4.dfsg-3 compression library - runtime

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt                    0.8.10.3+squeeze1 Advanced front-end for dpkg

-- no debconf information
[dpkg-1.16.2-stage1.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Thu, 12 Apr 2012 18:57:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 12 Apr 2012 18:57:02 GMT) Full text and rfc822 format available.

Message #29 received at 661538@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Gustavo Prado Alkmim <alkmim@ic.unicamp.br>
Cc: 661538@bugs.debian.org
Subject: Re: support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Thu, 12 Apr 2012 13:52:22 -0500
tags 661538 - patch
quit

Gustavo Prado Alkmim wrote:

> Patch updated to work on dpkg-1.16.2.

Same comments as before apply.

Hope that helps,
Jonathan




Removed tag(s) patch. Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Thu, 12 Apr 2012 18:57:10 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Fri, 13 Apr 2012 14:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wookey <wookey@wookware.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 13 Apr 2012 14:21:03 GMT) Full text and rfc822 format available.

Message #36 received at 661538@bugs.debian.org (full text, mbox):

From: Wookey <wookey@wookware.org>
To: 661538@bugs.debian.org
Subject: re: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Fri, 13 Apr 2012 15:18:48 +0100
[Message part 1 (text/plain, inline)]
Sorry I've let this languish rather - too many things to do. But
Alkmim tried actually using it and as has been pointed out above there
are omissions.

I've been meaning to start a thread on debian-devel to check that
there was reasonable consensus around this approach inorder to answer
the substantive question of 'are we really doing it this way?'. (And
to save us having a long debate on details in this bug prematurely).
I've not finished+sent that mail yet, but really will imminently now
precise is frozen. In the meatime getting a user+GSOC has prompted an
update. :-)

BTW that was alkmim's first ever bugrep above so thanks for being nice
to him.

Attached is a slightly better version which is at least useful enough to
work with.

I've added manpage info and corrected the broken code round setting
$buildstage.

So the current interface is that dpkg-buildpackage does not have a
comand-line option and just changes its behaviour if 
DEB_BUILD_OPTIONS=stage=1 is set (syntax copied from parallel=n),
whilst dpkg-chceckbuildopts does not do anything with magic ENV vars
but takes a --stage=n option.

This was because that's how I expect it to be used (cross-building
tools set the apropriate DEB_BUILD_OPTIONS item, and things 'just
work'), but adding the ENV parsing code to dpkg-checkbuilddepends
seemed unnecessary. I'm very happy to take advice on whether this is
the right interface semantics to use. 

Maybe I really should add a --stage=n option to dpkg-buildpackage too?
But do we really need more than one way to do this?

The old version of the patch didn't work well if stage=1 is set but no
Build-Depends-Stage1 is actualy present. (it carefully read no build
deps and thus found they were satisfied). Now if falls back to the
normal build deps if no staged build-deps are defined. We could
declare than an error instead, but that makes it harder to iterate
through a package set building and stage1 versions if present. I don't
have strong opinions here. 



Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
[dpkg-1.16.2-stage1.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Fri, 13 Apr 2012 15:57:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 13 Apr 2012 15:57:05 GMT) Full text and rfc822 format available.

Message #41 received at 661538@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Wookey <wookey@wookware.org>
Cc: 661538@bugs.debian.org
Subject: Re: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Fri, 13 Apr 2012 10:51:39 -0500
Wookey wrote:
(out of order for convenience)

> Attached is a slightly better version which is at least useful enough to
> work with.

Thanks.  What did you think of Raphaël's idea of the virtual
bootstrap-stage package?

Won't there be need for a Build-Conflicts-Stage1, too?

[...]
> I've been meaning to start a thread on debian-devel to check that
> there was reasonable consensus around this approach inorder to answer
> the substantive question of 'are we really doing it this way?'.

Ok, ok.

Aside from that sort of question, the Dpkg::Control::Fields numbering
still seems to be off.  Some people might think it is right to make
the maintainer do penance for this kind of fussy code, but I think
there are better ways to convince people to fix things. ;-)

I also was surprised that the patch did not have to touch the code in
"dpkg-source -b" that checks and normalizes Build-Depends so it could
be applied to Build-Depends-Stage1, too.  (See bug#254449.)  Is that
not needed?

The patch below (untested) fixes a few whitespace nits and the
Control::Fields numbering but not "dpkg-source -b".  Maybe it can save
some time.

Thanks again for your work,
Jonathan

diff --git i/man/deb-src-control.5 w/man/deb-src-control.5
index 15e9a911..7b627516 100644
--- i/man/deb-src-control.5
+++ w/man/deb-src-control.5
@@ -142,8 +142,8 @@ build-dependency loops when bootstrapping an architecture.
 
 .TP
 .BI Build\-Depends\-Indep\-Stage1: " package-list"
-Modified \fBBuild\-Depends\-Indep\fPA package list for building the source 
-package in 'bootstrap stage 1' mode. Staged builds are used to break 
+Modified \fBBuild\-Depends\-Indep\fPA package list for building the source
+package in 'bootstrap stage 1' mode. Staged builds are used to break
 build-dependency loops when bootstrapping an architecture.
 
 .TP
@@ -162,7 +162,7 @@ The syntax of the
 .B Build\-Depends\-Indep
 ,
 .B Build\-Depends\-Stage1
-and 
+and
 .B Build\-Depends\-Indep\-Stage1
 fields is a list of groups of alternative packages. Each group is a list
 of packages separated by vertical bar (or "pipe") symbols, "|". The
diff --git i/scripts/Dpkg/Control/Fields.pm w/scripts/Dpkg/Control/Fields.pm
index dbb041bf..fa16c8fc 100644
--- i/scripts/Dpkg/Control/Fields.pm
+++ w/scripts/Dpkg/Control/Fields.pm
@@ -61,32 +61,32 @@ our %FIELDS = (
     'Build-Conflicts' => {
         allowed => ALL_SRC,
         dependency => 'union',
-        dep_order => 3,
+        dep_order => 5,
     },
     'Build-Conflicts-Indep' => {
         allowed => ALL_SRC,
         dependency => 'union',
-        dep_order => 4,
+        dep_order => 6,
     },
     'Build-Depends' => {
         allowed => ALL_SRC,
         dependency => 'normal',
         dep_order => 1,
     },
-    'Build-Depends-Stage1' => {
+    'Build-Depends-Indep' => {
         allowed => ALL_SRC,
         dependency => 'normal',
-        dep_order => 1,
+        dep_order => 2,
     },
-    'Build-Depends-Indep' => {
+    'Build-Depends-Stage1' => {
         allowed => ALL_SRC,
         dependency => 'normal',
-        dep_order => 2,
+        dep_order => 3,
     },
     'Build-Depends-Indep-Stage1' => {
         allowed => ALL_SRC,
         dependency => 'normal',
-        dep_order => 2,
+        dep_order => 4,
     },
     'Built-Using' => {
         allowed => ALL_PKG,




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Fri, 11 May 2012 16:42:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wookey <wookey@wookware.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 11 May 2012 16:42:02 GMT) Full text and rfc822 format available.

Message #46 received at 661538@bugs.debian.org (full text, mbox):

From: Wookey <wookey@wookware.org>
To: 661538@bugs.debian.org
Subject: re: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Fri, 11 May 2012 17:38:41 +0100
[Message part 1 (text/plain, inline)]
> Jonathan Nieder <jrnieder@gmail.com> wrote:
> > Wookey wrote:
(out of order for convenience)

> Attached is a slightly better version which is at least useful enough to
> work with.

Thanks.  What did you think of Raphaël's idea of the virtual
bootstrap-stage package?

Interesting. We did look at various ways of representing this info in
the normal fields, but it was difficult to think of something that
was both sufficient and not too intrusive.

Raphael's idea could possibly work. The main problem seems to be if
you want to use a different build-dep (e.g foo-minimal rather
than foo). That gets a bit long-winded  (foo | bootstrap-stage (<<
99), bootstrap-stage (!= 2) | foo-minimal). A simple alternative list
is clearer.

Also this makes it hard for a tool to divine which build-stages are
available to build. Having -stageN headers also makes this very obvious. 

I'll read up the original docs where this was discussed at length and
see, then post on -devel (I have actually started said mail now!).

In the maintime I want to post this update of the existing scheme now for feedback.

> Won't there be need for a Build-Conflicts-Stage1, too?

In theory I suppose so, but in practice we've seen no use for it. I am
inclined to add this if we find it's necessary in the future.


> Aside from that sort of question, the Dpkg::Control::Fields numbering
> still seems to be off.  Some people might think it is right to make
> the maintainer do penance for this kind of fussy code, but I think
> there are better ways to convince people to fix things. ;-)

Sorry - I had failed to understand what those fields actually did. I
thought that as the -stage1 were alternative they would have the same
priority. It worked for my purposes without getting those right. I've
included your correcting in the new patch.

> I also was surprised that the patch did not have to touch the code in
> "dpkg-source -b" that checks and normalizes Build-Depends so it could
> be applied to Build-Depends-Stage1, too.  (See bug#254449.)  Is that
> not needed?

Well it seemed to work OK without touching that, but I agree it seems
wrong. I guess we were putting them all on one line, or didn't notice
the lost lines...

Fixed in new patch (but not tested yet). I need to add tests, as
suggested.

> The patch below (untested) fixes a few whitespace nits and the
> Control::Fields numbering but not "dpkg-source -b".  Maybe it can save
> some time.

It did - thanks.

One remaining issue is that packages built with stage=n set should
have their headers marked accordingly so they can be rejected from
repos or detected by scans. The suggestion in
http://wiki.debian.org/DebianBootstrap (specifying stages) says:

"Any 'staged' package must be identified as such in the metadata so it
is not accidentally uploaded as a 'real' package. Is the 'UNRELEASED'
codename indicator sufficient or do we need something more explicit:
e.g. X-Staged-Build:N header?"

I think the latter is a good idea, but it's not been implemented yet.
A clue as to where in the code to do that would be helpful. Is
dpkg-gencontrol the right place?

I notice the only other place that build-depends gets a mention is
dpkg-shlibs. Again not touching this has worked fine for us so far,
but maybe that should be adjusted too. I'm really not sure if it
matters?

Wookey
[dpkg-1.16.3-stage2.patch (text/x-diff, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Sat, 12 May 2012 02:48:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 12 May 2012 02:48:03 GMT) Full text and rfc822 format available.

Message #51 received at 661538@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Wookey <wookey@wookware.org>, 661538@bugs.debian.org
Subject: Re: Bug#661538: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Sat, 12 May 2012 04:46:00 +0200
I've not checked the details of the current proposed patch, as I think
the correct overall design should be agreed on first.

On Fri, 2012-05-11 at 17:38:41 +0100, Wookey wrote:
> > Jonathan Nieder <jrnieder@gmail.com> wrote:
> > > Wookey wrote:
> > Attached is a slightly better version which is at least useful enough to
> > work with.
> 
> Thanks.  What did you think of Raphaël's idea of the virtual
> bootstrap-stage package?

I don't like much the numbered stage fields, but I think abusing
virtual packages to do this is a bad idea, to the extent that I'd
rather use the numbered staged fields if there was no other option.

> Interesting. We did look at various ways of representing this info in
> the normal fields, but it was difficult to think of something that
> was both sufficient and not too intrusive.

I think I might have mentioned this before but I pondered about this
in more general terms some time ago in:

  <http://www.hadrons.org/~guillem/debian/docs/embedded.proposal>

From those, adding something like profiles support is IMO the nicer and
more generic solution, although it implies some infrastructure changes.
Of course other possible alternatives other people might come up with
might be even nicer, but my point is that we should strive to design
something that's good, ideally future-proof, somewhat generic, etc,
even if might imply more work, instead of trying to shove some
stuff into the system just because it implies minimal overall
infrastructure changes.

thanks,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Sat, 12 May 2012 04:24:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 12 May 2012 04:24:06 GMT) Full text and rfc822 format available.

Message #56 received at 661538@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: 661538@bugs.debian.org
Cc: Guillem Jover <guillem@debian.org>, Wookey <wookey@wookware.org>
Subject: Re: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Fri, 11 May 2012 23:20:43 -0500
Guillem Jover wrote:

>   <http://www.hadrons.org/~guillem/debian/docs/embedded.proposal>

Oh, neat.

Separate from questions of syntax and the list of supported values for
foo and bar in

	Build-Depends[foo bar]:

are some more basic questions about what happens to packages from a
bootstrap-stage1 build (or crush-style embedded build, etc --- the
same questions might apply there).

Are the resulting packages suitable for upload to the archive?

In the simplest case, a stage1 build produces the same sort of
packages as a full build would, just fewer of them.  Another way
to phrase the question: can that simplest case be the only case?

At the moment I am imagining a toolchain package, instead of a more
ordinary package that just has a complicated process for building
documentation.  So the product from a stage1 build can be
substantially different from the final build.

A part of me wants the answer to be "yes, these should be normal
packages".  So I might be able to use apt to install

	ghc-unregisterised

and use it to test later steps in a bootstrap process that ultimately
produces a "ghc" package without having to redo the unregisterised
build myself.

Downsides:

 - wasted time building the stage1-style packages during a normal
   build

 - wasted bandwidth and space for uploaded stage1-style packages
   after the initial bootstrap

 - complication from splitting out the stage1 product and giving
   it a different name from the full package

The opposite answer would be that the stage1 build product is allowed
to have limited functionality relative to a full package with the same
name and should only be used to satisfy build-dependencies for stage2
builds and then thrown away.  In that approach, as mentioned before
the binary packages should include a special field so the archive
knows to reject them.




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Sat, 12 May 2012 04:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 12 May 2012 04:51:03 GMT) Full text and rfc822 format available.

Message #61 received at 661538@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: 661538@bugs.debian.org
Cc: Guillem Jover <guillem@debian.org>, Wookey <wookey@wookware.org>
Subject: Re: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Fri, 11 May 2012 23:46:07 -0500
Jonathan Nieder wrote:

> Are the resulting packages suitable for upload to the archive?

After rereading <http://wiki.debian.org/DebianBootstrap>, looks
like the intended answer is "no".

[...]
>             So I might be able to use apt to install
>
> 	ghc-unregisterised

After rereading
<http://hackage.haskell.org/trac/ghc/wiki/Building/Porting>, an
automated bootstrap of ghc is not looking too easy, anyway.  The
only supported process seems to involve gathering some information
on the target and then cross-compiling.

[...]
>                               In that approach, as mentioned before
> the binary packages should include a special field so the archive
> knows to reject them.

Could you give some examples of differences between a stage1 build and
a full build that this procedure might be able to accomodate?  I know
skipping documentation processing steps might be one common trick; I'm
trying to figure out if more serious changes in the functionality
provided by a package might be involved.

What happens if my program grows more complicated and I need to add a
step that produces an even more limited package before what was
previously the stage1 build?  Do the stages of all other packages with
staged builds using my program have to be renumbered to make room?

Any conclusions about the semantics of the Build-Depends-Stage1 field
can be put into documentation in the dpkg repo so the next person
doesn't have to scratch their head so much. ;-)

Thanks,
Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Thu, 07 Jun 2012 20:06:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to "P. J. McDermott" <pjm@nac.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 07 Jun 2012 20:06:06 GMT) Full text and rfc822 format available.

Message #66 received at 661538@bugs.debian.org (full text, mbox):

From: "P. J. McDermott" <pjm@nac.net>
To: 661538@bugs.debian.org
Subject: Re: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Thu, 07 Jun 2012 15:58:22 -0400
On 2012-05-12 00:46, Jonathan Nieder wrote:
> Jonathan Nieder wrote:
>>                               In that approach, as mentioned before
>> the binary packages should include a special field so the archive
>> knows to reject them.
> 
> Could you give some examples of differences between a stage1 build and
> a full build that this procedure might be able to accomodate?  I know
> skipping documentation processing steps might be one common trick; I'm
> trying to figure out if more serious changes in the functionality
> provided by a package might be involved.

A staged binary package may indeed have limited functionality relative
to the full package.  Many packages can be built without some of their
dependencies – they might be configured to not link against certain
libraries or to not execute certain utilities during build time or run
time.  In many cases it is useful to build packages without these
optional ("soft") build dependencies to break dependency cycles –
resulting in a smaller set of binary packages and/or binary packages
with limited functionality.

> What happens if my program grows more complicated and I need to add a
> step that produces an even more limited package before what was
> previously the stage1 build?  Do the stages of all other packages with
> staged builds using my program have to be renumbered to make room?

Except for toolchain packages, there are so far no known cases in the
archive where more than one stage is necessary.

If a package becomes more complicated (e.g. introduces a library
dependency that would create a build dependency cycle), then that could
most likely be handled by simply not adding the new build dependency/ies
to "Build-Depends-Stage1".

If there is indeed a case in which that isn't sufficient and a new stage
is necessary as you propose, then yes, the stages must be renumbered in
debian/control and debian/rules.

-- 
P. J. McDermott                                        (_/@\_)    ,--.
http://www.pehjota.net/                           o    < o o >   / oo \
http://www.pehjota.net/contact.html                 o   \ `-/    | <> |.
                                                o o o    "~v    /_\--/_/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Thu, 07 Jun 2012 20:12:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "P. J. McDermott" <pjm@nac.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 07 Jun 2012 20:12:03 GMT) Full text and rfc822 format available.

Message #71 received at 661538@bugs.debian.org (full text, mbox):

From: "P. J. McDermott" <pjm@nac.net>
To: 661538@bugs.debian.org
Subject: Bug#661538: Patch generalization and field to mark staged packages
Date: Thu, 07 Jun 2012 16:02:27 -0400
Hi,

I have some ideas to finish the patch that has been proposed in this bug
report and hopefully address the concerns that have been raised.

I'm proposing these ideas before implementing them just because I've
only been programming in Perl and working with dpkg-dev code (beyond
simply looking at it) for about a week. :)


Generalization
==============

In practice it looks like no more than two stages will be necessary,
but, as Raphaël noted previously, it would be nice to have a more
general solution for stage numbering.  The current patch offers this in
dpkg-buildpackage, dpkg-checkbuilddeps, and dpkg-source.  The only place
in which stages 1 and 2 are statically defined is in the
Dpkg::Control::Fields module.

Rather than modifying a lot of dpkg code to handle field "patterns" or
the like, I propose a simple dynamic definition of "Build-Depends-
StageN" and "Build-Depends-Indep-StageN" hash elements in %FIELDS:

        'Build-Depends-Stage'.$buildstage => {
            allowed => ALL_SRC,
            dependency => 'normal',
            dep_order => 3,
        },

Then $buildstage could be defined by parsing DEB_BUILD_OPTIONS in
Dpkg::Control::Fields.


Staged Package Marking
======================

As mentioned previously by Wookey and Jonathan, staged binary packages
should be marked as such in their control files so they aren't
accidentally uploaded to the archive as complete packages.

To this end, I propose the addition of a new "Build-Stage: N" (or
similar) field.  This would of course be added to %FIELDS in
Dpkg::Control::Fields and be set (if "stage=N" is found in
DEB_BUILD_OPTIONS) by dpkg-gencontrol.

-- 
P. J. McDermott                                        (_/@\_)    ,--.
http://www.pehjota.net/                           o    < o o >   / oo \
http://www.pehjota.net/contact.html                 o   \ `-/    | <> |.
                                                o o o    "~v    /_\--/_/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Fri, 08 Jun 2012 06:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 08 Jun 2012 06:03:04 GMT) Full text and rfc822 format available.

Message #76 received at 661538@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: "P. J. McDermott" <pjm@nac.net>, 661538@bugs.debian.org
Subject: Re: Bug#661538: Patch generalization and field to mark staged packages
Date: Fri, 8 Jun 2012 08:00:07 +0200
Hi,

On Thu, 07 Jun 2012, P. J. McDermott wrote:
> Generalization
> ==============
[...]
> Rather than modifying a lot of dpkg code to handle field "patterns" or
> the like, I propose a simple dynamic definition of "Build-Depends-
> StageN" and "Build-Depends-Indep-StageN" hash elements in %FIELDS:
> 
>         'Build-Depends-Stage'.$buildstage => {
>             allowed => ALL_SRC,
>             dependency => 'normal',
>             dep_order => 3,
>         },
> 
> Then $buildstage could be defined by parsing DEB_BUILD_OPTIONS in
> Dpkg::Control::Fields.

This is not OK. It means that those fields would be basically unknown
when you're not doing a staged build. Yet they are always present
in debian/control (and probably the .dsc) and thus they need to exist
in that hash to avoid warnings, and to be able to output them in the
correct order, etc.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Fri, 08 Jun 2012 17:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Fri, 08 Jun 2012 17:30:03 GMT) Full text and rfc822 format available.

Message #81 received at 661538@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: "P. J. McDermott" <pjm@nac.net>
Cc: 661538@bugs.debian.org
Subject: Re: Patch generalization and field to mark staged packages
Date: Fri, 8 Jun 2012 12:27:12 -0500
P. J. McDermott wrote:

> As mentioned previously by Wookey and Jonathan, staged binary packages
> should be marked as such in their control files so they aren't
> accidentally uploaded to the archive as complete packages.
>
> To this end, I propose the addition of a new "Build-Stage: N" (or
> similar) field.  This would of course be added to %FIELDS in
> Dpkg::Control::Fields and be set (if "stage=N" is found in
> DEB_BUILD_OPTIONS) by dpkg-gencontrol.

Thanks --- yes, this would be a comfort.

Do I understand correctly that in the stage-N build, the installed
versions of all build-time dependencies (and their dependencies, et
cetera) must have build-stage >= (N-1)?  What about the standard
build?  Does it happen repeatedly, incrementing the stage number,
until the result is stable, or is there some other method for
approximating the limit? :)

Jonathan




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Sat, 09 Jun 2012 02:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wookey <wookey@wookware.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 09 Jun 2012 02:30:03 GMT) Full text and rfc822 format available.

Message #86 received at 661538@bugs.debian.org (full text, mbox):

From: Wookey <wookey@wookware.org>
To: 661538@bugs.debian.org
Subject: Re: Bug#661538: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Sat, 9 Jun 2012 03:26:43 +0100
Jonathan Nieder <jrnieder@gmail.com> wrote:

> Do I understand correctly that in the stage-N build, the installed
> versions of all build-time dependencies (and their dependencies, et
> cetera) must have build-stage >= (N-1)?  What about the standard
> build?  Does it happen repeatedly, incrementing the stage number,
> until the result is stable, or is there some other method for
> approximating the limit? :)

Good question.

No formal requirements have been specified along these lines, and I
don't think that they are needed, except to say that an uploadable
build should always be done against complete build-deps - anything
built against 'staged' packages must be considered 'tainted'.

So if we have 
A B-D: C-bin1
B B-D: A-bin1
C B-D: A-bin1,B-bin1

We untangle this by building A-stage1, B(tainted), C(tainted), A, B, C

Some code to note the tainting at build-time and mark the built package
accordingly would mean that nothing external needs to track this
state. I'm not sure how easy that is to do. 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Sat, 09 Jun 2012 04:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to "P. J. McDermott" <pjm@nac.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 09 Jun 2012 04:09:03 GMT) Full text and rfc822 format available.

Message #91 received at 661538@bugs.debian.org (full text, mbox):

From: "P. J. McDermott" <pjm@nac.net>
To: 661538@bugs.debian.org
Subject: Re: Bug#661538: Patch generalization and field to mark staged packages
Date: Fri, 08 Jun 2012 23:49:07 -0400
On 2012-06-08 02:00, Raphael Hertzog wrote:
> This is not OK. It means that those fields would be basically unknown
> when you're not doing a staged build. Yet they are always present
> in debian/control (and probably the .dsc) and thus they need to exist
> in that hash to avoid warnings, and to be able to output them in the
> correct order, etc.

Ah, yes, good point.

Then could you (or anyone else) suggest a way to handle "Build-Depends-
StageN" and "Build-Depends-Indep-StageN" fields for any values of "N"?
Any clues in this direction would be appreciated.  I'll look further
through the code tomorrow to see if I can come up with anything.

Thanks,
-- 
P. J. McDermott                                        (_/@\_)    ,--.
http://www.pehjota.net/                           o    < o o >   / oo \
http://www.pehjota.net/contact.html                 o   \ `-/    | <> |.
                                                o o o    "~v    /_\--/_/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Sat, 09 Jun 2012 04:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jonathan Nieder <jrnieder@gmail.com>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 09 Jun 2012 04:21:03 GMT) Full text and rfc822 format available.

Message #96 received at 661538@bugs.debian.org (full text, mbox):

From: Jonathan Nieder <jrnieder@gmail.com>
To: Wookey <wookey@wookware.org>
Cc: 661538@bugs.debian.org, "P. J. McDermott" <pjm@nac.net>
Subject: Re: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Fri, 8 Jun 2012 23:16:01 -0500
Wookey wrote:

>                                                      an uploadable
> build should always be done against complete build-deps - anything
> built against 'staged' packages must be considered 'tainted'.

Sounds good.  If I understand correctly:

* dpkg-checkbuilddeps: in a stage-N build, use Build-Depends-Stage<N>
  instead of Build-Depends.

* dpkg-checkbuilddeps: in a stage-N build, build-time dependencies
  must have Build-Stage >= N-1.

* dpkg-checkbuilddeps: in an untainted build, build-time dependencies
  must not have a Build-Stage field.

* dpkg-gencontrol: stage-N builds get "Build-Stage: N".

* dpkg-gencontrol: tainted builds, including stage-N builds, get
  "Do-Not-Upload: yes".

How does dpkg-gencontrol learn the build stage?  Is an envvar or a
file under debian/ used to communicate that information?




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Sat, 09 Jun 2012 07:33:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to "P. J. McDermott" <pjm@nac.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sat, 09 Jun 2012 07:33:03 GMT) Full text and rfc822 format available.

Message #101 received at 661538@bugs.debian.org (full text, mbox):

From: "P. J. McDermott" <pjm@nac.net>
To: 661538@bugs.debian.org
Subject: Re: Bug#661538: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Sat, 09 Jun 2012 03:31:43 -0400
On 2012-06-09 00:16, Jonathan Nieder wrote:
> Wookey wrote:
> 
>>                                                      an uploadable
>> build should always be done against complete build-deps - anything
>> built against 'staged' packages must be considered 'tainted'.
> 
> Sounds good.  If I understand correctly:
> 
> * dpkg-checkbuilddeps: in a stage-N build, use Build-Depends-Stage<N>
>   instead of Build-Depends.

Correct.  And the current revision of the patch already handles this.

> * dpkg-checkbuilddeps: in a stage-N build, build-time dependencies
>   must have Build-Stage >= N-1.

In probably most cases, there is only one staged binary package
installed at any one time (only long enough to build and install all of
the source package's full build dependencies).  Also, the order of
package building will be determined by the bootstrap build ordering tool
[1] that my fellow GSoC student Johannes Schauer will be developing.

> * dpkg-checkbuilddeps: in an untainted build, build-time dependencies
>   must not have a Build-Stage field.

Correct, but not really something that (according to the current plan –
see below) would be tracked by dpkg.

> * dpkg-gencontrol: stage-N builds get "Build-Stage: N".

Correct, this is what has been proposed.

> * dpkg-gencontrol: tainted builds, including stage-N builds, get
>   "Do-Not-Upload: yes".

This could be useful, but staged builds are already marked with a field.

"Tainted" builds could indeed be marked with "Do-Not-Upload: yes" or
similar, but as Wookey said it may or may not be easy to detect whether
a package fulfilling a build dependency was staged or complete.  The
current plan though is to simply track this information within the build
ordering tool.

> How does dpkg-gencontrol learn the build stage?  Is an envvar or a
> file under debian/ used to communicate that information?

The build stage is given in DEB_BUILD_OPTIONS, e.g.:

    $ DEB_BUILD_OPTIONS=stage=1 dpkg-buildpackage ...

I think the best way for dpkg-gencontrol to get this information is to
parse DEB_BUILD_OPTIONS for it directly (rather than through a
command-line option which would have to be given by debhelper and
anything else that calls dpkg-gencontrol).


[1]:
http://wiki.debian.org/SummerOfCode2012/StudentApplications/JohannesSchauer

-- 
P. J. McDermott                                        (_/@\_)    ,--.
http://www.pehjota.net/                           o    < o o >   / oo \
http://www.pehjota.net/contact.html                 o   \ `-/    | <> |.
                                                o o o    "~v    /_\--/_/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Wed, 13 Jun 2012 03:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "P. J. McDermott" <pjm@nac.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 13 Jun 2012 03:39:03 GMT) Full text and rfc822 format available.

Message #106 received at 661538@bugs.debian.org (full text, mbox):

From: "P. J. McDermott" <pjm@nac.net>
To: 661538@bugs.debian.org
Subject: Re: Bug#661538: Patch generalization and field to mark staged packages
Date: Tue, 12 Jun 2012 23:38:00 -0400
On 2012-06-08 23:49, P. J. McDermott wrote:
> Then could you (or anyone else) suggest a way to handle "Build-Depends-
> StageN" and "Build-Depends-Indep-StageN" fields for any values of "N"?
> Any clues in this direction would be appreciated.  I'll look further
> through the code tomorrow to see if I can come up with anything.

Looking through the uses of %FIELDS in Dpkg::Control::Fields, I've come
up with the following idea of a generic implementation to recognize
fields for any numbered build stage.

I propose supporting the use of regular expressions in %FIELDS keys.
Staged build dependency fields can then be defined generally as follows:

        'Build-Depends-Stage\d' => {
            allowed => ALL_SRC,
            dependency => 'normal',
            dep_order => 3,
        },
        'Build-Depends-Indep-Stage\d' => {
            allowed => ALL_SRC,
            dependency => 'normal',
            dep_order => 4,
        },

And the subroutines in Dpkg::Control::Fields that get values from
%FIELDS can call the following new subroutine to do so:

    sub field_get($) {
        my ($field) = @_;
        foreach my $key (keys %FIELDS) {
            return $FIELDS{$key} if $field =~ m/^$key$/;
        }
        return undef;
    }

This should be fairly unintrusive.  I'll test this further and check to
see if I've overlooked any complications before adding this to Wookey's
patch.  Does this solution look obviously wrong in any way?

Thanks,
-- 
P. J. McDermott                                        (_/@\_)    ,--.
http://www.pehjota.net/                           o    < o o >   / oo \
http://www.pehjota.net/contact.html                 o   \ `-/    | <> |.
                                                o o o    "~v    /_\--/_/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Wed, 13 Jun 2012 06:03:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 13 Jun 2012 06:03:06 GMT) Full text and rfc822 format available.

Message #111 received at 661538@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: "P. J. McDermott" <pjm@nac.net>, 661538@bugs.debian.org
Subject: Re: Bug#661538: Patch generalization and field to mark staged packages
Date: Wed, 13 Jun 2012 08:01:56 +0200
On Tue, 12 Jun 2012, P. J. McDermott wrote:
> And the subroutines in Dpkg::Control::Fields that get values from
> %FIELDS can call the following new subroutine to do so:
> 
>     sub field_get($) {
>         my ($field) = @_;
>         foreach my $key (keys %FIELDS) {
>             return $FIELDS{$key} if $field =~ m/^$key$/;
>         }
>         return undef;
>     }
> 
> This should be fairly unintrusive.  I'll test this further and check to
> see if I've overlooked any complications before adding this to Wookey's
> patch.  Does this solution look obviously wrong in any way?

It's sub-optimal. If we go that way, I would like:

1/ that you try direct access first, and fallback to use pattern matching
only if the direct access failed
2/ use pattern matching only on fields that actually are patterns (i.e.
you should tag them with a supplementary attribute, or you should put them
in a separate hash)

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Wed, 13 Jun 2012 15:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "P. J. McDermott" <pjm@nac.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 13 Jun 2012 15:42:03 GMT) Full text and rfc822 format available.

Message #116 received at 661538@bugs.debian.org (full text, mbox):

From: "P. J. McDermott" <pjm@nac.net>
To: 661538@bugs.debian.org
Subject: Re: Bug#661538: Patch generalization and field to mark staged packages
Date: Wed, 13 Jun 2012 11:39:44 -0400
On 2012-06-13 02:01, Raphael Hertzog wrote:
> It's sub-optimal. If we go that way, I would like:
> 
> 1/ that you try direct access first, and fallback to use pattern matching
> only if the direct access failed
> 2/ use pattern matching only on fields that actually are patterns (i.e.
> you should tag them with a supplementary attribute, or you should put them
> in a separate hash)

Fair enough.  I think a separate hash could address both of these points:

    sub field_get($) {
        my ($field) = @_;
        return $FIELDS{$field} if exists $FIELDS{$field};
        foreach my $key (keys %FIELDS_RE) {
            return $FIELDS_RE{$key} if $field =~ m/^$key$/;
        }
        return undef;
    }

Would this be acceptable?

Do you have a preference between the supplementary attribute and the
separate hash?

Thanks,
-- 
P. J. McDermott                                        (_/@\_)    ,--.
http://www.pehjota.net/                           o    < o o >   / oo \
http://www.pehjota.net/contact.html                 o   \ `-/    | <> |.
                                                o o o    "~v    /_\--/_/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Wed, 13 Jun 2012 18:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Raphael Hertzog <hertzog@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Wed, 13 Jun 2012 18:33:03 GMT) Full text and rfc822 format available.

Message #121 received at 661538@bugs.debian.org (full text, mbox):

From: Raphael Hertzog <hertzog@debian.org>
To: "P. J. McDermott" <pjm@nac.net>, 661538@bugs.debian.org
Subject: Re: Bug#661538: Patch generalization and field to mark staged packages
Date: Wed, 13 Jun 2012 20:30:39 +0200
On Wed, 13 Jun 2012, P. J. McDermott wrote:
> Fair enough.  I think a separate hash could address both of these points:
> 
>     sub field_get($) {
>         my ($field) = @_;
>         return $FIELDS{$field} if exists $FIELDS{$field};
>         foreach my $key (keys %FIELDS_RE) {
>             return $FIELDS_RE{$key} if $field =~ m/^$key$/;
>         }
>         return undef;
>     }
> 
> Would this be acceptable?

Yes.

> Do you have a preference between the supplementary attribute and the
> separate hash?

I tend to prefer the separate hash currently. If I change my mind during
the review, it's easy to convert to the other way.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Tue, 10 Jul 2012 01:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wookey <wookey@wookware.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 10 Jul 2012 01:21:03 GMT) Full text and rfc822 format available.

Message #126 received at 661538@bugs.debian.org (full text, mbox):

From: Wookey <wookey@wookware.org>
To: Guillem Jover <guillem@debian.org>
Cc: 661538@bugs.debian.org
Subject: Re: Bug#661538: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Tue, 10 Jul 2012 02:17:22 +0100
+++ Guillem Jover [2012-05-12 04:46 +0200]:
> I've not checked the details of the current proposed patch, as I think
> the correct overall design should be agreed on first.
> 
> I think I might have mentioned this before but I pondered about this
> in more general terms some time ago in:
> 
>   <http://www.hadrons.org/~guillem/debian/docs/embedded.proposal>
> 
> From those, adding something like profiles support is IMO the nicer and
> more generic solution, although it implies some infrastructure changes.

OK. I've looked at this again (finally) and I'm inclined to agree that
it seems a lot nicer than adding lots of Build-Depends-StageN fields.

As there are quite a lot of suggestions in the above doc, this is the
one I think Guillem is referring to and that seems good to me:

Set a 'profile' for a build. This could cover various needs including
the stageN bootstrap builds. I suggest the profile sould be set with 
DEB_BUILD_OPTIONS=profile=stage1 (rather than making up a new
variable DEB_BUILD_PROFILE). 

     Build-Depends: huge, tiny
     Build-Depends[stage1]: tiny
	    
    + Does not break current infrastrcture.
    + Allows alternatives as well as omitting build-deps
    + Does not overload existing syntax.
    - Duplicates part of the original field, which has to be kept
       in sync, although being side to side, it's easier to do than with
       a complete different whole directory.
	      
This has exactly the same functionality as my existing patch but a
more versatile syntax/mechanism and should involve much less
repetition in the implementation.

The only disadvantage I can see is the removal of the explicit
ordering of 'stage=1, stage=2' but it's not hard for a bootstraping
tool to know that the profiles 'stage1' and 'stage2' are reserved for
this usage. We could even put it in policy. 

I guess I should try implmenting it and see if there are any obvious
problems, but I can't see why there should be.

> Of course other possible alternatives other people might come up with
> might be even nicer, but my point is that we should strive to design
> something that's good, ideally future-proof, somewhat generic, etc,
> even if might imply more work, instead of trying to shove some
> stuff into the system just because it implies minimal overall
> infrastructure changes.

No argument from me there. 

We'll discuss this at debconf this week and see if anyone dislikes
this idea. 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Thu, 12 Jul 2012 03:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 12 Jul 2012 03:54:03 GMT) Full text and rfc822 format available.

Message #131 received at 661538@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Wookey <wookey@wookware.org>, 661538@bugs.debian.org
Subject: Re: Bug#661538: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Thu, 12 Jul 2012 05:51:14 +0200
On Tue, 2012-07-10 at 02:17:22 +0100, Wookey wrote:
> +++ Guillem Jover [2012-05-12 04:46 +0200]:
> > I've not checked the details of the current proposed patch, as I think
> > the correct overall design should be agreed on first.
> > 
> > I think I might have mentioned this before but I pondered about this
> > in more general terms some time ago in:
> > 
> >   <http://www.hadrons.org/~guillem/debian/docs/embedded.proposal>
> > 
> > From those, adding something like profiles support is IMO the nicer and
> > more generic solution, although it implies some infrastructure changes.
> 
> OK. I've looked at this again (finally) and I'm inclined to agree that
> it seems a lot nicer than adding lots of Build-Depends-StageN fields.

Thanks.

> As there are quite a lot of suggestions in the above doc, this is the
> one I think Guillem is referring to and that seems good to me:

Sorry for not being more clear on this, I guess I thought it was more
obvious from the previous context and it being the first option listed,
I was referring to:

 * Introducing build profiles (the specific characters '<>' could be
   changed, this is just an example):

   Build-Depends: huge (>= 1.0) [i386 arm] <!embedded !bootstrap>, tiny

   + Generic, it can solve other problems like bootstrapping.
   + Does not duplicate information.
   + Does not overload existing syntax.
   + Does not have the problem of mixed positive and negative arches.
   - This could only be deployed in Debian on etch+1 and started to be used
     on etch+2, that does not mean it cannot be used elsewhere beforehand
     given different release cycles.

> Set a 'profile' for a build. This could cover various needs including
> the stageN bootstrap builds. I suggest the profile sould be set with 
> DEB_BUILD_OPTIONS=profile=stage1 (rather than making up a new
> variable DEB_BUILD_PROFILE). 
> 
>      Build-Depends: huge, tiny
>      Build-Depends[stage1]: tiny
> 	    
>     + Does not break current infrastrcture.
>     + Allows alternatives as well as omitting build-deps
>     + Does not overload existing syntax.
>     - Duplicates part of the original field, which has to be kept
>        in sync, although being side to side, it's easier to do than with
>        a complete different whole directory.

> This has exactly the same functionality as my existing patch but a
> more versatile syntax/mechanism and should involve much less
> repetition in the implementation.

It has the serious disadvantage of duplicating build dependencies,
which can be quite error-prone when there are lots of them.

regards,
guillem




Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Tue, 17 Jul 2012 02:30:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "P. J. McDermott" <pjm@nac.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 17 Jul 2012 02:30:03 GMT) Full text and rfc822 format available.

Message #136 received at 661538@bugs.debian.org (full text, mbox):

From: "P. J. McDermott" <pjm@nac.net>
To: Guillem Jover <guillem@debian.org>, 661538@bugs.debian.org
Subject: Re: Bug#661538: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Mon, 16 Jul 2012 22:04:57 -0400
[Message part 1 (text/plain, inline)]
On 2012-07-11 23:51, Guillem Jover wrote:
> On Tue, 2012-07-10 at 02:17:22 +0100, Wookey wrote:
>> +++ Guillem Jover [2012-05-12 04:46 +0200]:
>>> I've not checked the details of the current proposed patch, as I think
>>> the correct overall design should be agreed on first.
>>>
>>> I think I might have mentioned this before but I pondered about this
>>> in more general terms some time ago in:
>>>
>>>   <http://www.hadrons.org/~guillem/debian/docs/embedded.proposal>
>>>
>>> From those, adding something like profiles support is IMO the nicer and
>>> more generic solution, although it implies some infrastructure changes.
>>
>> OK. I've looked at this again (finally) and I'm inclined to agree that
>> it seems a lot nicer than adding lots of Build-Depends-StageN fields.
> 
> Thanks.
> 
>> As there are quite a lot of suggestions in the above doc, this is the
>> one I think Guillem is referring to and that seems good to me:
> 
> Sorry for not being more clear on this, I guess I thought it was more
> obvious from the previous context and it being the first option listed,
> I was referring to:
> 
>  * Introducing build profiles (the specific characters '<>' could be
>    changed, this is just an example):
> 
>    Build-Depends: huge (>= 1.0) [i386 arm] <!embedded !bootstrap>, tiny
> 
>    + Generic, it can solve other problems like bootstrapping.
>    + Does not duplicate information.
>    + Does not overload existing syntax.
>    + Does not have the problem of mixed positive and negative arches.
>    - This could only be deployed in Debian on etch+1 and started to be used
>      on etch+2, that does not mean it cannot be used elsewhere beforehand
>      given different release cycles.

Out of curiosity, I implemented the above.  As I was able to borrow some
of the architecture specifications parsing logic and interfaces, profile
spec parsing was pretty simple to add.

The attached alternative patch makes dpkg-checkbuilddeps and Dpkg::Deps
parse and reduce build profiles (e.g. "<!embedded !stage1>") and makes
dpkg-gencontrol add a new "Build-Profile" field (like the previously
proposed "Build-Stage" field) to packages built with a profile.

Added to dpkg-buildpackage and dpkg-checkbuilddeps is a "-P<profile>"
option.  dpkg-buildpackage sets a "DEB_BUILD_PROFILE" environment
variable (unless it is already set) which is used by dpkg-checkbuilddeps
and dpkg-gencontrol.  (The new variable again follows the interface for
setting a host arch.)

The changes have been tested by building a package using
dpkg-buildpackage (with a "-P" option) and by directly running
debian/rules (with "DEB_BUILD_PROFILE" set).

The patch does not verify that the profile chosen by the user is
actually specified in the package's control file.  I'm not sure if (or
where) that should be done, but it would be fairly easy to do by listing
the "profiles" keys of all build dependencies.  Is similar checking done
for the host arch?

To be clear, this patch (an implementation of Guillem's "build profiles"
proposal) is a possible alternative to the previously considered
options.  We're not yet sure if all of the bootstrap dependency
information can be easily expressed in this build profiles syntax; I'll
be working to help determine this in the coming days and weeks.

So although I'm not proposing this for immediate inclusion, we'd
appreciate feedback on the design and implementation.

-- 
P. J. McDermott                                        (_/@\_)    ,--.
http://www.pehjota.net/                           o    < o o >   / oo \
http://www.pehjota.net/contact.html                 o   \ `-/    | <> |.
                                                o o o    "~v    /_\--/_/
[dpkg-build-profiles.debdiff (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Tue, 17 Jul 2012 03:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 17 Jul 2012 03:09:03 GMT) Full text and rfc822 format available.

Message #141 received at 661538@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: "P. J. McDermott" <pjm@nac.net>
Cc: 661538@bugs.debian.org
Subject: Re: Bug#661538: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Tue, 17 Jul 2012 05:02:41 +0200
Hi!

On Mon, 2012-07-16 at 22:04:57 -0400, P. J. McDermott wrote:
> On 2012-07-11 23:51, Guillem Jover wrote:
> > I was referring to:
> > 
> >  * Introducing build profiles (the specific characters '<>' could be
> >    changed, this is just an example):
> > 
> >    Build-Depends: huge (>= 1.0) [i386 arm] <!embedded !bootstrap>, tiny
> > 
> >    + Generic, it can solve other problems like bootstrapping.
> >    + Does not duplicate information.
> >    + Does not overload existing syntax.
> >    + Does not have the problem of mixed positive and negative arches.
> >    - This could only be deployed in Debian on etch+1 and started to be used
> >      on etch+2, that does not mean it cannot be used elsewhere beforehand
> >      given different release cycles.
> 
> Out of curiosity, I implemented the above.  As I was able to borrow some
> of the architecture specifications parsing logic and interfaces, profile
> spec parsing was pretty simple to add.

Cool, thanks!

> The attached alternative patch makes dpkg-checkbuilddeps and Dpkg::Deps
> parse and reduce build profiles (e.g. "<!embedded !stage1>") and makes
> dpkg-gencontrol add a new "Build-Profile" field (like the previously
> proposed "Build-Stage" field) to packages built with a profile.

I've only skimmed over it, but it looks good in principle (w/o having
checked every exact detail).

> Added to dpkg-buildpackage and dpkg-checkbuilddeps is a "-P<profile>"
> option.  dpkg-buildpackage sets a "DEB_BUILD_PROFILE" environment
> variable (unless it is already set) which is used by dpkg-checkbuilddeps
> and dpkg-gencontrol.  (The new variable again follows the interface for
> setting a host arch.)

Looks good.

> The changes have been tested by building a package using
> dpkg-buildpackage (with a "-P" option) and by directly running
> debian/rules (with "DEB_BUILD_PROFILE" set).

Great.

> The patch does not verify that the profile chosen by the user is
> actually specified in the package's control file.  I'm not sure if (or
> where) that should be done, but it would be fairly easy to do by listing
> the "profiles" keys of all build dependencies.  Is similar checking done
> for the host arch?

No, the builder should be able to use those unconditionally regardless
of the package having this kind of specifications, otherwise you'd
need to know if the package uses them to be able to first set the
flags, which does not really scale. Also the debian/rules could change
say configure options depending on the profile, and that's something
the dpkg tools would not be able to detect anyway.

> To be clear, this patch (an implementation of Guillem's "build profiles"
> proposal) is a possible alternative to the previously considered
> options.  We're not yet sure if all of the bootstrap dependency
> information can be easily expressed in this build profiles syntax; I'll
> be working to help determine this in the coming days and weeks.

Because the syntax should allow for positive and negative specifiers,
it should (in principle) allow all possible cases. But using this and
veryfing it's enough to cover all your needs would be helpful regardless.

> So although I'm not proposing this for immediate inclusion, we'd
> appreciate feedback on the design and implementation.

Before I'll consider including something like this, the aforementioned
deployment to see if it really covers all your needs would be nice,
and after that we'd need to propose and discuss this in for example
debian-devel, because other software will need to be adapted to
support the new syntax. I'll try to give a more detailed review of
the code in few days.

thanks,
guillem



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Tue, 17 Jul 2012 04:21:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "P. J. McDermott" <pjm@nac.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 17 Jul 2012 04:21:03 GMT) Full text and rfc822 format available.

Message #146 received at 661538@bugs.debian.org (full text, mbox):

From: "P. J. McDermott" <pjm@nac.net>
To: Guillem Jover <guillem@debian.org>, 661538@bugs.debian.org
Subject: Re: Bug#661538: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Tue, 17 Jul 2012 00:17:15 -0400
On 2012-07-16 23:02, Guillem Jover wrote:
> On Mon, 2012-07-16 at 22:04:57 -0400, P. J. McDermott wrote:
>> The patch does not verify that the profile chosen by the user is
>> actually specified in the package's control file.  I'm not sure if (or
>> where) that should be done, but it would be fairly easy to do by listing
>> the "profiles" keys of all build dependencies.  Is similar checking done
>> for the host arch?
> 
> No, the builder should be able to use those unconditionally regardless
> of the package having this kind of specifications, otherwise you'd
> need to know if the package uses them to be able to first set the
> flags, which does not really scale.

Yes, I thought that might be the case.

> Also the debian/rules could change
> say configure options depending on the profile, and that's something
> the dpkg tools would not be able to detect anyway.

Ah, yes, good point.  The detection I had in mind would have only
considered the Build-* control fields (which -- along with such
configure options, pkg-config variables, etc. -- is how we're doing
staged builds).

>> So although I'm not proposing this for immediate inclusion, we'd
>> appreciate feedback on the design and implementation.
> 
> Before I'll consider including something like this, the aforementioned
> deployment to see if it really covers all your needs would be nice,
> and after that we'd need to propose and discuss this in for example
> debian-devel, because other software will need to be adapted to
> support the new syntax.

Sounds good to me.

I've already modified sbuild to use the new profile reduction in
Dpkg::Deps, though I've yet to test and publish the patch.  I also
started looking at what'll need done in APT.

> I'll try to give a more detailed review of
> the code in few days.

Alright, great.

Thanks for the feedback,
-- 
P. J. McDermott                                        (_/@\_)    ,--.
http://www.pehjota.net/                           o    < o o >   / oo \
http://www.pehjota.net/contact.html                 o   \ `-/    | <> |.
                                                o o o    "~v    /_\--/_/



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Sun, 19 Aug 2012 04:39:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to "P. J. McDermott" <pjm@nac.net>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Sun, 19 Aug 2012 04:39:03 GMT) Full text and rfc822 format available.

Message #151 received at 661538@bugs.debian.org (full text, mbox):

From: "P. J. McDermott" <pjm@nac.net>
To: 661538@bugs.debian.org
Subject: Re: Bug#661538: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Sun, 19 Aug 2012 00:34:43 -0400
[Message part 1 (text/plain, inline)]
On 2012-07-16 23:02, Guillem Jover wrote:
> I'll try to give a more detailed review of
> the code in few days.

Have you had a chance to review this patch?

Since my last mail, I realized that:

  * I forgot some documentation for Dpkg::Deps::deps_parse(), and
  * A "use_profile" option was missing from deps_parse().

Attached is a patch in which these issues are corrected.

Thanks,
-- 
P. J. McDermott                                        (_/@\_)    ,--.
http://www.pehjota.net/                           o    < o o >   / oo \
http://www.pehjota.net/contact.html                 o   \ `-/    | <> |.
                                                o o o    "~v    /_\--/_/
[dpkg-build-profiles.debdiff (text/plain, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Mon, 20 Aug 2012 02:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Mon, 20 Aug 2012 02:42:03 GMT) Full text and rfc822 format available.

Message #156 received at 661538@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: "P. J. McDermott" <pjm@nac.net>, 661538@bugs.debian.org
Subject: Re: Bug#661538: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Mon, 20 Aug 2012 04:37:56 +0200
Hi!

On Sun, 2012-08-19 at 00:34:43 -0400, P. J. McDermott wrote:
> On 2012-07-16 23:02, Guillem Jover wrote:
> > I'll try to give a more detailed review of
> > the code in few days.
> 
> Have you had a chance to review this patch?

Sorry, not yet, I took some time off Debian, but I hope to take a
look around this week. In any case, I'll be queueing it on one of my
local branches to start testing it somewhat.

> Since my last mail, I realized that:
> 
>   * I forgot some documentation for Dpkg::Deps::deps_parse(), and
>   * A "use_profile" option was missing from deps_parse().

Cool, thanks!

regards,
guillem



Added indication that bug 661538 blocks 695243 Request was from Jonathan Nieder <jrnieder@gmail.com> to control@bugs.debian.org. (Thu, 06 Dec 2012 07:03:09 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Tue, 22 Jan 2013 12:51:11 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wookey <wookey@wookware.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 22 Jan 2013 12:51:11 GMT) Full text and rfc822 format available.

Message #163 received at 661538@bugs.debian.org (full text, mbox):

From: Wookey <wookey@wookware.org>
To: Guillem Jover <guillem@debian.org>
Cc: 661538@bugs.debian.org
Subject: Re: Bug#661538: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Tue, 22 Jan 2013 12:47:47 +0000
+++ Guillem Jover [2012-07-17 05:02 +0200]:
> Hi!
> 
> On Mon, 2012-07-16 at 22:04:57 -0400, P. J. McDermott wrote:
> > On 2012-07-11 23:51, Guillem Jover wrote:
> > > I was referring to:
> > > 
> > >  * Introducing build profiles (the specific characters '<>' could be
> > >    changed, this is just an example):
> > > 
> > >    Build-Depends: huge (>= 1.0) [i386 arm] <!embedded !bootstrap>, tiny
> > > 
> > 
> > Out of curiosity, I implemented the above.  As I was able to borrow some
> > of the architecture specifications parsing logic and interfaces, profile
> > spec parsing was pretty simple to add.
> 
> Cool, thanks!

> Before I'll consider including something like this, the aforementioned
> deployment to see if it really covers all your needs would be nice,
> and after that we'd need to propose and discuss this in for example
> debian-devel, because other software will need to be adapted to
> support the new syntax. I'll try to give a more detailed review of
> the code in few days.

OK. So we've spent 6 months satisfying ourselves that there is no
technical problem with this design, and have started a debian-devel
thread: http://lists.debian.org/debian-devel/2013/01/msg00329.html

There seems good acceptance of the build-profile concept and need for
a solution to the bootrapping issue. There is some discussion of 
a) the best syntax , and 
b) exactly how granular build-profiles should be, including
fundamentally whether to allow more than one at a time.

It would be useful if you gave any feedback you have in that thread
before we try to sumarise a final plan.

We (the bootstrappers) don't care at all about syntax, so long as it
works. Using <> is clear, the argument that we should avoid using
up metacharacters if we don't have to is also sound. Ultimately I
think it's a choice for the dpkg maintainers.

On single/multiple profiles I think I favour relatively granular
profiles for specific purposes (cross, check, stageN) which means more
than one at a time should be allowed. This will be more flexible in
the long term allowing them to be used for a lot more than just
bootstrapping. Some thought about exactly what setting 2 or
3 profiles means in practical terms will be needed. 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Tue, 22 Jan 2013 17:00:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Guillem Jover <guillem@debian.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Tue, 22 Jan 2013 17:00:03 GMT) Full text and rfc822 format available.

Message #168 received at 661538@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: Wookey <wookey@wookware.org>
Cc: 661538@bugs.debian.org
Subject: Re: Bug#661538: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Tue, 22 Jan 2013 17:56:41 +0100
On Tue, 2013-01-22 at 12:47:47 +0000, Wookey wrote:
> +++ Guillem Jover [2012-07-17 05:02 +0200]:
> > Before I'll consider including something like this, the aforementioned
> > deployment to see if it really covers all your needs would be nice,
> > and after that we'd need to propose and discuss this in for example
> > debian-devel, because other software will need to be adapted to
> > support the new syntax. I'll try to give a more detailed review of
> > the code in few days.
> 
> OK. So we've spent 6 months satisfying ourselves that there is no
> technical problem with this design, and have started a debian-devel
> thread: http://lists.debian.org/debian-devel/2013/01/msg00329.html

Thanks for that! And yes I've seen it, I've just been letting it sink
in and sleeping over some of the things said on the thread.

> It would be useful if you gave any feedback you have in that thread
> before we try to sumarise a final plan.

Sure, was planning on finishing some other things first and replying
this week.

Thanks,
Guillem



Information forwarded to debian-bugs-dist@lists.debian.org, Dpkg Developers <debian-dpkg@lists.debian.org>:
Bug#661538; Package dpkg-dev. (Thu, 12 Sep 2013 03:27:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Wookey <wookey@wookware.org>:
Extra info received and forwarded to list. Copy sent to Dpkg Developers <debian-dpkg@lists.debian.org>. (Thu, 12 Sep 2013 03:27:05 GMT) Full text and rfc822 format available.

Message #173 received at 661538@bugs.debian.org (full text, mbox):

From: Wookey <wookey@wookware.org>
To: Guillem Jover <guillem@debian.org>, 661538@bugs.debian.org
Subject: Re: Bug#661538: Add support for Build-Depends-Stage1 in order to allow breaking of cyclic Build-depends loops
Date: Thu, 12 Sep 2013 04:25:58 +0100
+++ Guillem Jover [2013-01-22 17:56 +0100]:
> On Tue, 2013-01-22 at 12:47:47 +0000, Wookey wrote:
> > +++ Guillem Jover [2012-07-17 05:02 +0200]:
> > > Before I'll consider including something like this, the aforementioned
> > > deployment to see if it really covers all your needs would be nice,
> > > and after that we'd need to propose and discuss this in for example
> > > debian-devel, because other software will need to be adapted to
> > > support the new syntax. I'll try to give a more detailed review of
> > > the code in few days.
> > 
> > OK. So we've spent 6 months satisfying ourselves that there is no
> > technical problem with this design, and have started a debian-devel
> > thread: http://lists.debian.org/debian-devel/2013/01/msg00329.html
> 
> Thanks for that! And yes I've seen it, I've just been letting it sink
> in and sleeping over some of the things said on the thread.
> 
> > It would be useful if you gave any feedback you have in that thread
> > before we try to sumarise a final plan.

So there has since been a thread on the debian-dpkg list:
https://lists.debian.org/debian-dpkg/2013/04/msg00017.html

resulting in a spec proposal which has been written up here:
https://wiki.debian.org/BuildProfileSpec
which after https://lists.debian.org/debian-dpkg/2013/08/msg00011.html
was expanded to cover both possible syntaxes.

We'd really like some feedback from the dpkg maintainer on what we
should do next, and which syntax to update the patches for.

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/



Added indication that bug 661538 blocks 728820 Request was from Simon McVittie <smcv@debian.org> to submit@bugs.debian.org. (Tue, 05 Nov 2013 21:36:07 GMT) Full text and rfc822 format available.

Added tag(s) pending. Request was from Guillem Jover <guillem@debian.org> to control@bugs.debian.org. (Thu, 05 Dec 2013 05:51:12 GMT) Full text and rfc822 format available.

Message sent on to Wookey <wookey@debian.org>:
Bug#661538. (Thu, 05 Dec 2013 05:51:20 GMT) Full text and rfc822 format available.

Message #180 received at 661538-submitter@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: 661538-submitter@bugs.debian.org
Subject: Bug#661538 marked as pending
Date: Thu, 05 Dec 2013 05:49:08 +0000
tag 661538 pending
thanks

Hello,

Bug #661538 reported by you has been fixed in the Git repository. You can
see the changelog below, and you can check the diff of the fix at:

    http://git.debian.org/?p=dpkg/dpkg.git;a=commitdiff;h=7662e09

---
commit 7662e0937bb064a0754d12605d80a96a17e2aadf
Author: Guillem Jover <guillem@debian.org>
Date:   Wed Dec 4 05:56:17 2013 +0100

    Add experimental build profiles support
    
    This adds the basic infrastructure support for a new class of generic
    build-time dependency restrictions, and in particular implements the
    specific build profiles, which will allow to cull build dependencies
    depending on the profile being used. There's several things this can
    be used for, like new port bootstrapping, reduced package builds, and
    similar. In the future other kinds of restrictions could be added as
    the build profiles are namespaced with “profile.”. An example field
    could be:
    
      Build-Depends: exotic-compiler, libneeded-dev, tool-tiny,
       tool-huge (>= 1.0) [linux-any] <!profile.embedded !profile.bootstrap>
    
    or even stuff like:
    
      Depends: net-tools <profile.network>, plugin-curl <!profile.no-plugins>
    
    The generated binary packages and .changes files will get a new
    Built-For-Profiles field containing the active profiles during the build.
    
    In addition the build profile can be selected using the environment
    variable DEB_BUILD_PROFILES, with space separated values, such as:
    
      DEB_BUILD_PROFILES="embedded bootstrap"
    
    The management and possible registration in the profile namespace is
    currently out of scope in dpkg, this should probably be handled by a
    distribution specific process.
    
    See draft <http://www.hadrons.org/~guillem/debian/docs/embedded.proposal>.
    
    Closes: #661538
    
    Based-on-patch-by: Patrick "P. J." McDermott <pjm@nac.net>
    Based-on-patch-by: Wookey <wookey@debian.org>
    Based-on-patch-by: Johannes Schauer <j.schauer@email.de>
    Signed-off-by: Guillem Jover <guillem@debian.org>

diff --git a/debian/changelog b/debian/changelog
index aba5303..d64383c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -109,6 +109,14 @@ dpkg (1.17.2) UNRELEASED; urgency=low
     the array in a subsequent package processing. Closes: #726112
   * Do not accept empty field names in dpkg.
   * Do not accept an initial hyphen in field names.
+  * Add experimental build profiles support:
+    - Add support for <!profile.name> build-time restrictions in dependencies.
+    - Add support for DEB_BUILD_PROFILES environment variable.
+    - Add new option -P to dpkg-buildpackage and dpkg-checbuilddeps.
+    - Add new Built-For-Profiles output field in .deb and .changes files.
+    Based on a patch by Patrick "P. J." McDermott <pjm@nac.net>,
+    Wookey <wookey@debian.org> and Johannes Schauer <j.schauer@email.de>.
+    Closes: #661538
 
   [ Updated programs translations ]
   * German (Sven Joachim).



Reply sent to Guillem Jover <guillem@debian.org>:
You have taken responsibility. (Thu, 05 Dec 2013 06:06:28 GMT) Full text and rfc822 format available.

Notification sent to Wookey <wookey@debian.org>:
Bug acknowledged by developer. (Thu, 05 Dec 2013 06:06:28 GMT) Full text and rfc822 format available.

Message #185 received at 661538-close@bugs.debian.org (full text, mbox):

From: Guillem Jover <guillem@debian.org>
To: 661538-close@bugs.debian.org
Subject: Bug#661538: fixed in dpkg 1.17.2
Date: Thu, 05 Dec 2013 06:03:48 +0000
Source: dpkg
Source-Version: 1.17.2

We believe that the bug you reported is fixed in the latest version of
dpkg, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 661538@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Guillem Jover <guillem@debian.org> (supplier of updated dpkg package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Thu, 05 Dec 2013 04:56:31 +0100
Source: dpkg
Binary: libdpkg-dev dpkg dpkg-dev libdpkg-perl dselect
Architecture: source amd64 all
Version: 1.17.2
Distribution: unstable
Urgency: low
Maintainer: Dpkg Developers <debian-dpkg@lists.debian.org>
Changed-By: Guillem Jover <guillem@debian.org>
Description: 
 dpkg       - Debian package management system
 dpkg-dev   - Debian package development tools
 dselect    - Debian package management front-end
 libdpkg-dev - Debian package management static library
 libdpkg-perl - Dpkg perl modules
Closes: 32427 71106 143307 187019 257505 583585 615813 661538 667008 681370 717983 718437 718541 718899 718945 719418 719746 719844 720712 725437 726112 726932 729874
Changes: 
 dpkg (1.17.2) unstable; urgency=low
 .
   [ Guillem Jover ]
   * Make Dpkg::Arch debwildcard_to_debtriplet() more robust by matching
     on exact 'any' strings, instead of substrings.
   * Add manpages-it Replaces to dselect and dpkg-dev. Closes: #717983
     Reported by Andreas Beckmann <anbe@debian.org>.
   * Document default dpkg-deb compressor change to xz in man page.
     Thanks to Salvatore Bonaccorso <carnil@debian.org>. Closes: #718437
   * Version manpages-it in Replaces with (<< 2.80-4), now that the package
     does not ship the overlapping paths any more.
   * Automatically prepend needed spaces for continuation --force-help lines.
   * Be more precise on deb format errors with data member in dpkg-deb.
   * Do not allow deb packages with control and data members swapped.
   * Clarify «dpkg-deb --extract» bad usage error message on missing arguments
     by printing all required arguments at once. Closes: #718899
   * Clarify the insertion order of _ members in deb(5) man page.
   * Fix use after free in alternative_parse_fileset() on update-alternatives.
     Reported by Pedro Ribeiro <pedrib@gmail.com>.
   * Fix use after free in dpkg_arch_load_list() on libdpkg.
     Reported by Pedro Ribeiro <pedrib@gmail.com>.
   * Fix theoretical stack buffer overflow in w_dependency() on libdpkg, not
     currently applicable. Reported by Pedro Ribeiro <pedrib@gmail.com>.
   * Add ppc64el support to cputable. Closes: #718945
     Thanks to Jeff Bailey <jeffbailey@google.com>.
   * Use dpkg-gencontrol -c argument as a fallback lock file in case
     debian/control does not exist. Closes: #667008
   * Pass the package reference count (i.e. number of present instances) to
     maintainer scripts via the new variable DPKG_MAINTSCRIPT_PACKAGE_REFCOUNT.
     Closes: #681370
   * Fix field names on error messages in libdpkg, by either capitalizing them
     or by renaming them to match reality.
   * Do not capitalize error and warning messages.
   * When ignoring invalid remove requests in dpkg consider that progress,
     reset the loop detector and avoid the assert. Closes: #143307
   * Activate all path components for file triggers on removal.
     Regression introduced in 1.17.0. Closes: #725437
   * Activate file triggers on disappearance more accurately, only when we know
     we are inevitably removing things.
   * Fix «dpkg-query --list» output when using multibyte character strings,
     to avoid unaligned columns and mojibake. Closes: #257505, #718541
     Based on a patch by Changwoo Ryu <cwryu@debian.org>.
   * Use fully buffered output on non-tty stdout.
     Reported by Shawn Landden <shawnlandden@gmail.com>.
   * Recognize «start-stop-daemon -C» as documented. Closes: #719746
     Reported by Brian S. Julin <bri@abrij.org>.
   * When update-alternatives is told to change slave links, do not warn that
     the link group is broken, just print a notice that the alternative is
     being updated due to the changes.
   * Add a new «dpkg --verify» command to check the integrity of packages
     installed files. Add a --verify-format option to excplicitly select the
     output format, currently only rpm compatible output is supported, but
     the default might change in the future. Closes: #187019
   * Improve dpkg “Preparing to replace” and “Unpacking” progress messages.
     Closes: #32427, #71106
   * Print the package version on main dpkg progress messages.
   * Do not store timestamps in gzip headers when using the command, to try to
     mimic the zlib behavior. This does not affect Debian as it's been using
     zlib for a very long time. Closes: #719844
   * Reset environment variables affecting compressor commands when not using
     the shared library implementations. Namely XZ_DEFAULTS, XZ_OPT, BZIP and
     BZIP2.
   * Use a simple list to track packages owning a file, instead of using a
     list of arrays of pointers which waste 10 pointers per non-shared file,
     instead of 1. This significantly reduces dpkg memory usage.
   * Honor new DEB_SIGN_KEYID environment variable in dpkg-buildpackage.
     Suggested by Harald Dunkel <harri@afaics.de>. Closes: #615813, #719418
   * Always check subprocess exit codes in Dpkg::Source::Package modules.
     Reported by Ian Jackson <ijackson@chiark.greenend.org.uk>.
   * Add support for pie and stack-protector options to dpkg-buildflags FFLAGS,
     and update the man page to mention FFLAGS are a subset of CFLAGS.
     Closes: #726932
   * Improve and unify -O option handling in dpkg-genchanges, dpkg-gensymbols
     and dpkg-shlibdeps, by always taking an optional filename argument and
     describing in the man page the default output files.
   * Use “hyphen” instead of “dash” when we mean the ‘-’ character in the
     documentation and code comments.
   * Do not NULL-terminate the list in the compat scandir(), as this might
     cause a segfault in case the function returns 0 entries.
   * Always return from ensure_statoverrides() if file is NULL, otherwise
     we might get us to read garbage from memory or segfault.
   * Add new symlink_to_dir command to dpkg-maintscript-helper. Closes: #720712
     Based on a patch by Bastien ROUCARIÈS <roucaries.bastien@gmail.com>.
   * Add new dir_to_symlink command to dpkg-maintscript-helper. Closes: #583585
   * Distinguish dpkg error reports between errors while processing packages
     and archives.
   * Fix crashes in the first call to gettext() after fork() on Mac OS X, by
     forcing the initialization at program start of the CoreFoundation cached
     values in libintl.
   * Set a default gettext domain for libdpkg code, so that other programs
     using a different domain can still get correct translations, like dselect.
   * Cleanup libdpkg-perl API:
     - Dpkg::Compression: Deprecate $default_compression_level,
       $default_compression and $compression_re_file_ext package variables.
     - Dpkg::Exit: Deprecate @handlers package variable.
     - Dpkg::Source::Package: Deprecate $diff_ignore_default_regexp and
       @tar_ignore_default_pattern package variables.
     - Dpkg::Changelog::Entry::Debian: Deprecate $regex_header and
       $regex_trailer package variables.
   * Add GnuPG 2.x support. Add gnupg2 and gpgv2 as alternative Recommends to
     gnupg and gpgv (to not pull them by default), but prefer gpgv2 over gpgv,
     and gpg2 over gpg at run-time if they are available.
   * Switch dpkg conflictor tracking from a fixed-size array to a queue,
     fixing several related issues, due to conflictors not being removed from
     the array after processing them. dpkg could fill it due to additions in
     previous package processing producing very confusing error messages; and
     a theoretical problem where a package could get appended to be removed,
     then reinstalled as a new version, to get removed again when revisiting
     the array in a subsequent package processing. Closes: #726112
   * Do not accept empty field names in dpkg.
   * Do not accept an initial hyphen in field names.
   * Add experimental build profiles support:
     - Add support for <!profile.name> build-time restrictions in dependencies.
     - Add support for DEB_BUILD_PROFILES environment variable.
     - Add new option -P to dpkg-buildpackage and dpkg-checbuilddeps.
     - Add new Built-For-Profiles output field in .deb and .changes files.
     Based on a patch by Patrick "P. J." McDermott <pjm@nac.net>,
     Wookey <wookey@debian.org> and Johannes Schauer <j.schauer@email.de>.
     Closes: #661538
   * Bump Standards-Version to 3.9.5.
   * Document interactions of dpkg-source --extend-diff-ignore and -i in the
     man page. Closes: #729874
 .
   [ Updated programs translations ]
   * German (Sven Joachim).
   * Vietnamese (Trần Ngọc Quân).
 .
   [ Updated scripts translations ]
   * German (Helge Kreutzmann).
 .
   [ Updated manpages translations ]
   * French (Christian Perrier): fix incorrectly translated sentence,
     thanks to Fabien Givors.
   * German (Helge Kreutzmann).
Checksums-Sha1: 
 c4f7042c038c3174f6f170e359d59e167788fe03 2005 dpkg_1.17.2.dsc
 ef6d6e3dba5be41b86e1befe1cf86b51adaaaf36 3829700 dpkg_1.17.2.tar.xz
 df8f5ee146fad7af246f627e7f9a338e89e219f8 735532 libdpkg-dev_1.17.2_amd64.deb
 d66336876dd4aac3caa2d2f27a5742f40dc48d4c 2599582 dpkg_1.17.2_amd64.deb
 5391ca8e435ac4c9a9e5e3f4f599e6d0ddfa0ff2 995850 dselect_1.17.2_amd64.deb
 b2ba52087ebbac112b4a2c63700e79e5d91928cb 1376728 dpkg-dev_1.17.2_all.deb
 25356eba113913a90863be668cdf24f2625896a0 905766 libdpkg-perl_1.17.2_all.deb
Checksums-Sha256: 
 c99d474673f45a85156dcdc3173d899ef6decbfead599b87026000770538239f 2005 dpkg_1.17.2.dsc
 0a1c2b4d7a5a485b53263448c0a6f111ca4fe5d774cddf0abd7ce02758db8650 3829700 dpkg_1.17.2.tar.xz
 6812d5ea71c7ba237452589eb81a14ab10fd16e456ebc761063b20c71f61cd35 735532 libdpkg-dev_1.17.2_amd64.deb
 1f667dad1a22f215c762efaaf2d4dc2c3db0c5c61f1bc6982785a6a9b3edc4b9 2599582 dpkg_1.17.2_amd64.deb
 f5cd2208024a044b2c40f3e78ea592f0da312203524d282b79c6f0113ba4e103 995850 dselect_1.17.2_amd64.deb
 ba5198eec4b67ba616197493fc7a143c2a0781910436b49c13003350fae72788 1376728 dpkg-dev_1.17.2_all.deb
 b660b588f508c5a066dd6d995c805bf8896085bb182280343400bae5198b1f25 905766 libdpkg-perl_1.17.2_all.deb
Files: 
 c53e4ebc6dbcde14397a060c1357e569 2005 admin required dpkg_1.17.2.dsc
 35d42dac927d31152a22f50637994d51 3829700 admin required dpkg_1.17.2.tar.xz
 aa991c285663d59e84fa8642bd548ff3 735532 libdevel optional libdpkg-dev_1.17.2_amd64.deb
 3ed7cbafd833e43648984871bb090d05 2599582 admin required dpkg_1.17.2_amd64.deb
 411f6bda343a2df4e7d630b03b99140a 995850 admin optional dselect_1.17.2_amd64.deb
 6c36f5b1450d965afe038b5577730c44 1376728 utils optional dpkg-dev_1.17.2_all.deb
 28900795bce285bf30a5f2f917a271b9 905766 perl optional libdpkg-perl_1.17.2_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (GNU/Linux)

iQIcBAEBCAAGBQJSoAcoAAoJELlyvz6krlejSNwQAOSerUBsifpUSSPK0rc4YB4E
knkRqIcEEiWmjYKddLHS58fy7h6AXPz/OO55+iiN093eDSaDF1KSM4HT7k2Ev8sq
r7n4MNCLHyVajM/mnvIYnihbm/jJZmHkGmBMLmirsJTY7mpopLE+BRI8QFXb0fiJ
oawlPspvQcs5bFvZUiUxuSyWGhuYs+TIP+3+rMEX0Xe4+//N577lmO8GEUOnBMVf
7jqxn02yAvqE/pIv208WFWW+Go3B/7jhudOeDBPoHIf3JyxMQhSkFEccSYUM+yXB
mvNOi44hrhG9w7J1tQEuMHXqnPmSIp87bcoqTCFGjuDqRJNHM/fTCJuYsYSFbNDl
MlxLqN6Oq0AmWEiakrPYHBgJR5LZDhCMohOlbp4D7GW3wtjz4Z4uddXq4xL8aItE
o+rl44J86iOqwBCkZ/iQYFaIirjosl5souso3AOsg2igumrkdB0y1q1HeKUjtXma
k4byEj0FEpwh03HAbABQv3LDm4UKwL7QF9D8gDZ5emCGH9JbuHFeO+N/6yB9LS+A
rHa1bedUbfLoBiWtBx+eTGfSCLBj0U9mI2MuEusItvR9xsC+KuCnt4sIRwpwuymt
GF8yqMw0FMSDa6Aavcn0U9EPYS+vPtSiV23CKljP5kI8DHSVxUGbto3pkfbtGqtg
sw0ZOWT/NClNjVfpezTY
=5lAo
-----END PGP SIGNATURE-----




Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Thu, 02 Jan 2014 07:28:23 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Fri Apr 18 17:11:15 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.