[modular-debian] Standardized Build Option Documentation

  • From: "David L. Craig" <dlc.usa@xxxxxxxxx>
  • To: modular-debian@xxxxxxxxxxxxx
  • Date: Mon, 15 Dec 2014 02:24:57 -0500

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?
<not cent from sell>
May the LORD God bless you exceedingly abundantly!

"So the universe is not quite as you thought it was.
 You'd better rearrange your beliefs, then.
 Because you certainly can't rearrange the universe."

Attachment: signature.asc
Description: Digital signature

Other related posts: