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 /_\--/_/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
