On Thu, 2008-09-11 at 08:46 +0200, Raphael Hertzog wrote: > On Wed, 10 Sep 2008, Bill Allombert wrote: > > > > People have noticed that and already requested that we can call > > > > arbitrary > > > > targets of debian/rules with all the proper initialization done > > > > precisely > > > > for test purpose during packaging work (see #477916). > > > > > > I must say, I really do not like this direction. debhelper and cdbs and > > > similar sytsems are the places to provide this help where people want to > > > use it, in my opinion.
The actual support will be implemented in debhelper - all that is needed
is a consistent manner to pass the same options to debhelper across a
range of packages. Packages then add extra support if necessary, e.g. if
a package installs docs manually instead of using dh_installdocs, then
those sections of debian/rules need to be either conditionally excluded:
ifeq (,$(findstring nodocs,$(DEB_BUILD_OPTIONS)))
install foo.1 debian/foo/usr/share/man/man1/
...
endif
or redone for debhelper support via foo.install files, etc.
After Lenny, I will be filing bugs for this support - at least for the
packages used in Emdebian.
> We have a lot of past experience with that and we
> > > have the compatibility level to handle smoothing transitions. (And to
> > > provide a way for people to never transition, I admit, and I see where
> > > that's the problem that you're solving, but I prefer that problem to the
> > > problems introduced by the instability of having the package build
> > > infrastructure change the input to the builds without coordination with
> > > the package.)
There has to be coordination with the package - the package needs to
support the build option, either explicitly or via debhelper. All CDBS
or any other layer needs to do is pass down the option to make it
accessible to debhelper (usually via DEB_BUILD_OPTIONS).
> > I like to say I concurr with Russ. There are some much difference
> > between packages that distributions wide default does not make sense.
On the contrary, there are clear divisions where distribution-wide build
options do make sense. Raphael correctly identifies nodocs and nocheck
as the current Emdebian distribution-wide build options. nodocs itself
needs to be refined to allow for graded levels of documentation
exclusion and other build options may change the build process itself -
all under the control of the particular package. If the package does not
understand the option, nothing happens.
e.g. Emdebian needs nodocs (or something as broad) that drops
everything, from README and TODO to changelog.gz and manpages during the
build, rather than after downloading. Preferably, nodocs would also lead
to the mandatory compression of copyright to save more space. It is not
new for DEB_BUILD_OPTIONS to break Debian Policy - supporting a
distribution-wide superset of options allows the use of the set to
conform to Emdebian Policy etc.
Other uses of options could use graduations so that examples are dropped
but not the rest, or just manpages or just HTML docs etc. Dpkg Classes
will help with graduations, as long as the distro can afford to remove
the files *after* the package has been downloaded.
> But more and more people want to be able to change distribution wide
> default: Emdebian wants to enable "nodocs" and "nocheck" by default, other
> want to be able to enable hardening options by default and I agree with
> them that official support for such a facility is desirable.
>
> See also #498355 and #498380 for such requests from Emdebian.
Note also that Ubuntu are interested in supporting distribution-wide
build options.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: This is a digitally signed message part
