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

Re: Introducing Build-Recommends / Build-Core-Depends?



* Andreas Barth [2011-08-13 13:28 +0200]:
> Also, the binary packages in the debian/control template could have
> Build-Depends specified which means that they should only be built if
> those packages are actually installed ...

An optional "Build-Depends:" field per binary package as you described
is essentially the same as the following, with the notable difference,
that the below could appear as it is in the output of, i.e., apt-cache
showsrc without requiring maintainers of all those packages to invent
a new syntax just to enable users and developers to look up information.

    Build-Depends[foo-stage1]: debhelper
    Build-Depends[foo-stage2]: debhelper, libx11-dev
    Build-Depends: debhelper, libx11-dev, libgnome2-dev


> Building with core Dependencies only
>
> If doing an build of the core functionality only, norecommends is
> added to the environment DEB_BUILD_OPTIONS.

How do I build foo-stage1, but not foo-stage2?  With a binary option
like the above, it does not seem to be possible, unless
dpkg-buildpackage decides based on the installed packages which packages
it builds.  Doing so might require using equivs if in early
bootstrapping stages a part of the build dependencies is manually
compiled instead of installed via dpkg, and it might waste time if
dpkg-buildpackage decides to build a large binary package that is not
needed yet.

The most obvious ways to specify which packages should be build seem to
be mybikeisred=[foo-stage1,...] added to the environment
DEB_BUILD_OPTIONS or a new optional environment variable
DEB_BUILD_PACKAGES which would contains a comma separated list of to be
built packages and an additional make target binary-pkg-foo-stage1 in
debian/rules.


To prevent building packages needed for bootstrapping only by default,
a new field in the source package's paragraph of the control file could
be used, e.g., "NotBuiltByDefault: foo-stage1, foo-stage2".  Not adding
such a field to the binary package's paragraph instead has the same
reason as described at the beginning of my mail.


Regards
Carsten


Reply to: