[Soc-coordination] Status Report for Bootstrappable Debian, Week 2

[Peter Pentchev]

On Sat, May 24, 2014 at 04:05:15AM +0300, Peter Pentchev wrote:
> In my opinion, this first week was mostly dipping my toes in and testing
> the water, setting up a workflow...
[snip]
> ...that no bugs have been filed yet, either against src:krb5 or against
> src:flex; I'm still figuring out whether this is the best way to do it.
> In the future, I certainly expect to be able to convert more than one
> new package per week :)

In the second week I filed pairs of bugs against several packages.
The bugs come in pairs - build patches and control patches - because
the versions of the Debian packaging and build tools (dpkg, apt, sbuild,
etc) in the stable distribution do not support build profiles yet, thus
packages using the full build profiles functionality and annotations
will FTBFS when passed to the buildds.  So there is first the "build"
patchset that teaches the debian/rules file to look at the
DEB_BUILD_PROFILES environment variable and, if it contains the word
"stage1", skip part of the build process and pass the appropriate
options to the Debian packaging tools to actually not put together some
of the binary packages (e.g. -Nlibraw1394-doc for debhelper).  This
patch may be applied to the package and the result may be uploaded to
the Debian archive right now - since the buildds will never put anything
meaningful in DEB_BUILD_PROFILES, the binary packages will have no
changes whatsoever.  Still, if somebody decides to bootstrap a Debian
distribution on a new architecture, there will be the option to set
DEB_BUILD_PROFILES to "stage1", remove some of the build dependencies
and build a limited version, only the binary packages that are needed
for the next step.

The second patchset, the "control" one, usually consists of three parts,
two in debian/control and one in debian/rules:
- add a <!profile.stage1> annotation to the dropped build dependencies
- add a Build-Profiles: !stage1 line to the omitted binary package
  stanzas
- remove the DH_OPTIONS or whatever setting was used in debian/rules,
  since the Debian package building framework (debhelper, cdbs, etc)
  will see the Build-Profiles header in debian/control now

So, following this model, I filed pairs of bootstrapping patch wishlist
bugs against several packages:
- src:flex - #749344 (build), #749470 (control)
- src:libtasn1-6 - #749854 (build), #749855 (control)
- src:libraw1394 - #749989 (build), #749990 (control)
- src:gpm - #749616 (both, the texlive dependency is not used at all
  and can be dropped with no change to the binary package, but breaking
  the circular build dependency)

For flex I also filed #749341 to drop additional build dependencies and
Manoj Srivastava kindly applied the patch at once.

In the middle of the week Johannes Schauer updated the Feedback Arc Set
that I use for determining which packages need which build dependencies
dropped, so I updated my progress table at
https://wiki.debian.org/CircularBuildDependencies#The_Feedback_Arc_Set

All in all, I feel that this week there was some progress, not just in
the actual filing of bugs, but also in that I gained some real-world
experience in converting packages using several kinds of build systems
(most of them use debhelper with override rules, but libtasn1-6 uses
cdbs, while gpm and python-defaults, which I'm working on at the moment,
both use debhelper 5 style rules files with explicit lists of the dh_*
commands to be executed).  From this point on converting a new package
should be faster, in some cases almost routine.

G'luck,
Peter

-- 
Peter Pentchev	roam at ringlet.net roam at FreeBSD.org p.penchev at storpool.com
PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
What would this sentence be like if it weren't self-referential?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/soc-coordination/attachments/20140601/4d7a1df0/attachment.sig>