[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#229357: Can we require build-arch/indep targets for lenny?



On Sun, Jul 01, 2007 at 05:22:31PM +0200, Bill Allombert wrote:
> On Sat, Jun 30, 2007 at 09:40:29AM +0200, Andreas Metzler wrote:
> > I think that is just wrong. sbuild should not need to know anything
> > about dpkg-buildpackage's internals and there is no need for change
> > here. The currently used and proven interface is:

> > 1. install Build-Depends for running dpkg-buildpackage -B

> The issue we are trying to fix is that the current combination of 
> Debian policy and dpkg-buildpackage actually require
> Build-Depends-Indep to be installed when running dpkg-buildpackage -B.

> Indeed dpkg-buildpackage -B calls 'debian/rules build' which
> requires Build-Depends-Indep to be installed. Since buildd actually
> implement 1) this cause packages to FTBFS until they are 'fixed' by
> having 'build' not depending on 'build-indep' (or equivalently, the
> build-indep task being performed directly by binary-indep), which is
> against the spirit of policy (because build-indep will then be 
> executed under sudo or fakeroot).

> So this interface is used and proven to be wrong.

Attached is a patch to dpkg which implements a check for a 'build-arch'
target using 'make -f debian/rules -qn build-arch'.

I looked into using make -pn, but Guillem Jover pointed out that this
doesn't work if the 'build-arch' target is implemented using patterns. 
'-qn' appears the most reliable option; this is the same basic technique
that was attempted once before and reverted by Adam Heath, the dpkg
maintainer at the time, so I spoke with him about the reasons for the revert
and it appears the concerns are mostly about dpkg behavior on systems that
do not conform to Debian policy.

I don't think that's a good enough reason to stall innovation that benefits
Debian, but perhaps the current dpkg maintainers do; I'll try to lay out the
technical details impartially for their consideration so they can make an
informed decision.

I believe the attached patch has the following characteristics:

- Any packages in Debian that currently have existing but /broken/
  'build-arch' targets will fail to build because of the failure of this
  target.
- Any packages that have a debian/rules which is not a valid Makefile will
  continue to build as before (the new code will conclude that there is no
  valid 'build-arch' target).
- Packages in Debian that have a 'build-arch' target will have this target
  used instead of 'build' when 'dpkg-buildpackage -B' is called.
- Packages in Debian that do not have a 'build-arch' target will continue to
  have their 'build' target called by 'dpkg-buildpackage -B'.
- Behavior on systems where 'make' is not GNU make is undefined.
  Specifically, on such a system dpkg is likely to either conclude that
  /all/ packages support 'build-arch', or that /none/ of them support
  'build-arch', depending on whether and how 'make -qn' fails.

This has the following further implications:

- Barring any buggy 'build-arch' targets, all packages that currently build
  on Debian autobuilders should continue to build successfully and
  correctly.
- Packages that do support 'build-arch' today will also build faster,
  because the indep build will now be skipped.
- Packages that do not yet support 'build-arch' can adopt this target
  without any need for coordinated changes on the buildds.
- Packages that include in their Build-Depends field build-dependencies
  which are only needed for the architecture-independent portion of the
  'build' target can move these build-dependencies to Build-Depends-Indep as
  soon as they have a 'binary-arch' target that does not depend on the
  'build' target, and a working 'build-arch' target that does not perform
  the related architecture-independent build operations.  Packages that make
  this change to their Build-Depends field should also build-depend on the
  version of dpkg-dev introducing these semantics.

Documenting this in policy should be straightforward if these changes to
dpkg are accepted.

Lucas has agreed to doing a full archive rebuild with a modified dpkg-dev,
for comparison with the previous test.  A dpkg-dev binary including this
change can be found at
<http://people.debian.org/~vorlon/dpkg-dev_1.14.4-0.1_all.deb>.

Cheers,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@debian.org                                   http://www.debian.org/
diff -Nru /tmp/MWAqJMfVFu/dpkg-1.14.4/debian/changelog /tmp/V6mOrMQZzb/dpkg-1.14.4/debian/changelog
--- /tmp/MWAqJMfVFu/dpkg-1.14.4/debian/changelog	2007-05-24 09:30:41.000000000 -0700
+++ /tmp/V6mOrMQZzb/dpkg-1.14.4/debian/changelog	2007-07-02 12:28:01.000000000 -0700
@@ -1,3 +1,14 @@
+dpkg (1.14.4-0.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Detect 'build-arch' target if present using make -f debian/rules -qn, and
+    use it instead of 'build' when called with -B.  This allows maintainers
+    who have a build-arch target to use Build-Depends-Indep for any
+    build-dependencies that are only used in the build/binary-indep/binary
+    targets, with no further coordination required.  Closes: #229357.
+
+ -- Steve Langasek <vorlon@debian.org>  Mon, 02 Jul 2007 10:14:20 -0700
+
 dpkg (1.14.4) unstable; urgency=low
 
   [ Guillem Jover ]
diff -Nru /tmp/MWAqJMfVFu/dpkg-1.14.4/scripts/dpkg-buildpackage.sh /tmp/V6mOrMQZzb/dpkg-1.14.4/scripts/dpkg-buildpackage.sh
--- /tmp/MWAqJMfVFu/dpkg-1.14.4/scripts/dpkg-buildpackage.sh	2007-05-08 20:09:33.000000000 -0700
+++ /tmp/V6mOrMQZzb/dpkg-1.14.4/scripts/dpkg-buildpackage.sh	2007-07-02 12:09:11.000000000 -0700
@@ -226,7 +226,33 @@
 	cd ..; withecho dpkg-source $passopts $diffignore $tarignore -b "$dirn"; cd "$dirn"
 fi
 if [ x$sourceonly = x ]; then
-	withecho debian/rules build 
+	USE_BUILD_ARCH=0
+	if [ "$binarytarget" = "binary-arch" ]; then
+		set +e
+		make -f debian/rules -qn build-arch 2>/dev/null
+		MAKE_RETVAL=$?
+		set -e
+		# either make returned success (meaning we have a valid
+		# makefile, a valid invocation of make, and an
+		# up-to-date target of the given name) or it returned 1
+		# (meaning we have a target of the given name which is
+		# not up-to-date, or we have a non-GNU make that happens
+		# to return 1 on an invalid make invocation or an
+		# invalid makefile).  This means dpkg-buildpackage will
+		# be looking for a build-arch target instead of build
+		# target in some corner-case systems that are so 
+		# un-Debian-like that half of Debian's packages don't
+		# build anyway due to  GNU make assumptions in
+		# debian/rules.
+		if [ "$MAKE_RETVAL" = 1 ] || [ "$MAKE_RETVAL" = 0 ]; then
+			USE_BUILD_ARCH=1
+		fi
+	fi
+	if [ "$USE_BUILD_ARCH" = 1 ]; then
+		withecho debian/rules build-arch
+	else
+		withecho debian/rules build 
+	fi
 	withecho $rootcommand debian/rules $binarytarget
 fi
 if [ "$usepause" = "true" ] && \

Reply to: