user debian-pol...@packages.debian.org
usertags 604397 + normative discussion
quit

(please consider dropping policy Bug#604397 or dpkg-buildpackage Bug#229357
from replies)
Hi,

Roger Leigh wrote:
[out of order for convenience]

> Just for the record, I've implemented support in debhelper's dh
> command in #604563.  Once applied, this will automatically add support
> to the huge chunk of the archive using "tiny" rules files.  cdbs will
> be next on my list.

debhelper 8.1.0 has such support now.  Thanks!

>> * Roger Leigh <rle...@debian.org>, 2010-11-21, 21:38:

>>> I'd like to propose that build-arch and build-indep be changed in
>>> Policy from "may be provided" to "must be provided" in preparation
>>> for enabling their use.

Personally, I'm all for it; ideally it would happen in the following
order:

 1. Providing build-arch and build-indep becomes a best practice.
    lintian gains a check.  devref encourages the practice.

 2. Becomes a policy "should".

 3. Becomes a policy "must".

That sounds slow, no?  Yes, that's the point.  I'd like to propose
that we not make most of the packages in the archive instantly RC
buggy, today.

>>> We've wanted to fix the root problem for
>>> at least half a decade, and I'd like to get it done for wheezy.

I just noticed this gem in policy ยง4.9:

        If one or both of the targets build-arch and build-indep are
        not provided, then invoking debian/rules with one of the
        not-provided targets as arguments should produce a exit status
        code of 2.  Usually this is provided automatically by make if
        the target is missing.

So it seems to me that "dpkg-buildpackage -B" ought to be taught to
run the equivalent of

        debian/rules build-arch
        if test "$?" = 2
        then
                debian/rules build
        fi

.  In http://bugs.debian.org/72335 the only argument against that I
see is

        (and notwithstanding that we're going to require both or neither), it
        should say that "debian/rules -q with one of the not-provided targets
        ...", because the programs which will want to test this are likely to
        do something cheap like:

        debian/rules -q build-arch
        if [ $? -eq 2 ]; then
            debian/rules build
        else
            debian/rules build-arch
        fi

        To try a full build only to receive an exit status of 2 would not say
        whether the build failed or the target was not found.

That doesn't seem so compelling to me; in the failure case, the
autobuilder would just try to pick up where it left off and fail
again, which doesn't sound so expensive.  What am I missing?

Thanks for moving this forward.

Regards,
Jonathan



--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to