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

Bug#604397: debian-policy: require build-arch and build-indep targets



On Fri, Jun 03, 2011 at 11:32:13PM -0500, Jonathan Nieder wrote:
> > I don't think a policy "should" actually moves us down that road, because
> > there's no actual penalty for not complying.  The issue is *not* that
> > maintainers don't, in general, implement this target (in fact, it's been
> > around forever in the dh_make templates),

> As a counterexample, I did not implement the target in any packages I
> worked on unless they actually could benefit from the
> build-arch/build-indep distinction.  There was simply no obvious
> reason to do it, and the documentation gave no hint that it was a good
> idea.  The devref would be a better place to put that suggestion given
> the current state of things, but to say that documenting it somewhere
> would accomplish nothing seems like overstating things.

I'm saying it won't accomplish enough to be a worthwhile intermediate step,
and want us to get back to figuring out a roadmap that would enable us to
turn on build-arch handling on the buildds this cycle.

> > And if we want to provide a smooth transition instead, using something like
> > Joey's proposed make-first-existing-target interface in bug #598534 (as
> > discussed on debian-devel in
> > http://lists.debian.org/debian-devel/2010/09/msg00704.html)

> I was about to say: without a full archive rebuild there is no
> guarantee that that would actually provide a smooth transition,
> either, since the build-arch targets are not well tested in isolation.
> But that was misguided of me:

> Assuming that the "build" target depends on "build-arch" and
> "build-indep" and does nothing for itself, the most frightening
> obvious case is a package that does too little in build-arch, relying
> on build-indep to generate some other files (e.g., manpages) that are
> needed for binary-arch.  Typically binary-arch would depend on build
> in that case, so while breakage of this kind is possible, I don't
> imagine it would be widespread.

> So I'm all for this.  A test rebuild would still be comforting, of
> course.

Given that you seem to have argued in this same mail for providing both an
intermediate dpkg-buildpackage switch, and introducing a Build-Options field
that would have to be populated manually, I'm a little unclear: do you think
make-first-existing-target is a sufficient solution for the buildds, or not?
If you don't think it is, can you point to any problems with the
implementation?

> > The patch is outstanding; the make maintainer is TTBOMK currently
> > unavailable for Debian work.  If there's a consensus on
> > debian-policy/devel/ctte that we should go the make-first-existing-target
> > route, I would be more than happy to do an NMU of make to facilitate this.

> Thanks much!  If you'd like, I can try out the two patches from
> Bug#598534 and send a comparison there.

Thanks for the offer.  How do you plan to try them out?  Are you proposing a
full-archive rebuild?

> By the way, shouldn't the make package be orphaned to reflect the
> current reality?  Totally unrelated to the above, I would like to work
> with the maintainer to see the latest upstream version of "make"
> packaged in experimental, but for a while now the maintainer has been
> hard to reach.

I think it would be reasonable to let the MIA team know about Manoj's
protracted absence (DevRef 7.4).

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature


Reply to: