[modular-debian] Re: Standardized Build Option Documentation

  • From: Joel Roth <joelz@xxxxxxxxx>
  • To: modular-debian@xxxxxxxxxxxxx
  • Date: Mon, 15 Dec 2014 07:46:32 -1000

Hi David,

First, thanks for these thoughtful comments.

On Mon, Dec 15, 2014 at 02:24:57AM -0500, David L. Craig wrote:
> Thanks primarily to the systemd proponents, we find
> ourselves evaluating alternatives to Debian.  I say thanks
> because it has compelled us to grapple with many things
> Debian did for us without forcing upon us too many choices
> we had to bear with.  On many of these particulars we folks
> on this list may not agree, of course.  I believe we all
> agree, however, user choice is the prime directive for
> any distro to be produced by us Debian-systemd refugees.
> 
> Now we must separate two layers of defining distributions:
> binary and source.  Debian does both although most users
> treat the Debian source as a black box so they need not
> run make as a matter of course.  Such users must accept
> the build choices made by those who package the sources
> into binary packages.  Is this list solely in that camp?
> 
> Let me assume it is not for the sake of this essay.
> I consider this to be a reasonable assumption.  If modular
> Debian is a source distribution, like LFS, CRUX, and
> Gentoo, then we maximize user choices, providing the
> strongest argument in favor of a source basis.  The cost
> of infrastructure to rebuild source packages has never
> been lower--probably the second-strongest argument.

> Now Gentoo has standardized compile-time variables that
> have cross-package associations into its USE facility.
> CRUX, at the other end of the spectrum, ignores them--it is
> the responsibility of every user to dig into the available
> options of all source packages, evaluate their defaults,
> and override whatever is indicated.  Modular Debian
> should likely find a design consensus closer to Gentoo
> than to CRUX.
> 
> Now source packages in the coursest granularity are
> very similar--the standard build recipe is applied,
> and configure scripts are the lingua franca.  However,
> when you dig down into finer granuality, you see many
> packages are uncommon--in some ways, they are configured
> and built differently (perhaps quite subtlely) from any
> other package.
> 
> The big problem is the documentation of these particulars
> is often suboptimal from the user's perspective.  In many
> cases it is deep inside the source code.  Some amount
> of research is needed to fully grok any package: its
> configuarable options, its interdependencies with other
> source packages, and the relative importance of those
> various options and interdependencies.  This increases the
> workload of every user that decides to build an unfamiliar
> (or substantially rewritten) package; in some cases,
> dramatically.  This is probably the strongest argument
> against a source basis distribution.  The second-strongest
> argument from my point of view is it is easier to support
> a distro that does not facilitate customized executables.
> 
> Is there a better way than state-of-the-art employed by
> any source-based distribution?  Is Gentoo's USE facility
> the best mankind can do?  I hope not.

> What is needed is standardized documentation formats
> that all package developer/documenter providers (or their
> proxies, distro developers) can employ to define up front
> everything a user needs to know to fully configure the
> software for his or her usage.  Properly designed and
> implemented, these standardized build man page files should
> enable automata to be created to dialog with the user at
> an opportunity to make a choice (possibly subject to a
> user-defined threshold) about a configuration option to be
> applied to the system being built, perhaps with multiple
> scopes of applicability.  If you will, we need something
> comparable to what debconf does for binary packages, or at
> least the documentation to much more easily do it manually.
> 
> Comments?  Are there facilities I have yet to encounter
> that address this concept?

Knowing how to configure the linux kernel for various
intended purposes presents a somewhat analogous problem.
What set of kernel options are necessary and sufficient
for a particular task?

Since selecting a set of kernel options that will work
together well is a hard problem, preparing a pared-down
kernel for a particular purpose is not easy. There is no
wizard that can guide you fully.

The last time I configured the kernel, make menuconfig had a
way of grouping options that was helpful, and had short
documentation for many of them, including a suggested
choice.  

How can you tell someone what kernel options she should
use?  

The ability to install and remove modules on a running
kernel is convenient and simultaneously less secure. A
conservative administrator might disable loadable kernel
modules.  The people who use linux for realtime audio
processing will want scheduling and other kernel features
according to that.

There are references, as well as compiled kernels,
but no high-level configurator has succeeded up to now,
AFAIK. It only works at the level of the individual config
options, with some features grouped together.

So some experts get together, and we have the
general-purpose kernels provided by various distros. 

At the application and library level, even knowledgeable
users generally just install a binary package until a more
carefully configured build is needed. 

I would be interested to know what your criticisms of 
gentoo USE variables.[1] Here is an example.

| [ Found these USE variables for app-office/gnumeric-1.6.3 ]
|  U I
|  - - debug  : Enable extra debug codepaths, like asserts and extra output.
|               If you want to get meaningful backtraces see
|               http://www.gentoo.org/proj/en/qa/backtraces.xml .
|  + + gnome  : Adds GNOME support
|  + + python : Adds support/bindings for the Python language
|  - - static : !!do not set this during bootstrap!! Causes binaries to be
|               statically linked instead of dynamically
 


1. https://wiki.gentoo.org/wiki/Handbook:X86/Working/USE


-- 
Joel Roth
  


Other related posts: