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

Feaping Creature-ism in core Debian Packages

Sorry for the ambiguous title, but the subject matter of this posting is
likely to be a bit broad in the beam, and scattered in its contacts.

I had this weekend to play with the Ultra. I have been able to build
kernels for about a week now and looked to build glibc and get started
fleshing out a "standard" system.

Building glibc is pretty straight forward, given the great work that Joel
has done with this monster, (thanks Joel!) and you don't need much more
than the tools for building a kernel to build these library packages. I
found, however, that for the current source I needed a later version of
make than the one I had installed. No problem, I had already added it to
the source tree I was building, so I went there and ran dpkg-buildpackage,
only to find that to build a Debian package for make, I needed texi2html
installed, or the rules file failed. (I could, at this time, have simply
commented out these lines from the rules file, done without having docs in
policy directed format, and gone on with building glibc, but I chose to
try to fix the problem)

tetex-bin provides texi2html, so I tried to build tetex-bin: which needs
flex to be installed, which needs byacc in order to build flex, and byacc
is built using debhelper. debhelper will not build (I believe because perl
is not installed...heaven forbid that perl be built with debhelper!), so I
simply installed the binary-all package.

It should be noted here that this is a circumstance where an important
package (glibc) rightly depends on a standard package(make), which rightly
depends on a standard package (tetex-bin), which depends on the standard
package flex, which depends for its construction on the extra package
byacc (anyone know why this is an extra package?), which can not be built
without the optional package "debhelper". By this long indirect route,
glibc becomes dependent for its construction upon an optional package.
This chain elevates debhelper to the defacto level of standard...and there
is no reason for it to do so. (see later rant)

OK, so I got flex built, and took a second crack at tetex-bin, discovering
that I needed the xlib6g-dev package! While this is a standard package,
most of the packages built by its source (xfree86) are optional!

So now I'm in the process of resolving the source dependencies for xfree86
(currently building bison...), and am beginning to wonder just how much of
the distribution I will need to build before I can actually build glibc!

While the parts of xfree86 that are needed _are_ considered standard
packages, they can only be bootstrapped from the complete source, which is
considered optional (aside from being a bear to build). What are the
chances for having the xlib6g packages split off at the source level? All
of the packages that are required by glibc will need to be built at least
twice (once using the old libraries, and the second time using the newly
created libraries), so keeping this pile of code down to as small as
possible is a priority for autobuilding processes.

What to do?

My first knee-jerk reaction is to fix the problem at my first point of

Why does the "make" package process need to depend upon texi2html? Because
policy directs the documentation to appear in html format for the general
document reader tools. But this does not mean that building the source for
"make" need call this routine. Just as the menu system can let different
packages provide the registration information for their menu items, which
are collected and implimented whenever the menu package gets installed, so
to could packages like "make" identify their doc format and location for
later translation by the "docs" package that will expect them in html and
a particular location for proper re-formating and placement. This would
free packages like "make" from having source dependencies on large
document managment packages with their own complex dependencies.

debhelper rant

Please don't get me wrong, I am NOT opposed to helper packages. What I AM
opposed to is helper packages that work by inserting external calls into
the debian/rules file. This guarantees that the package will require the
helper scripts be installed _before_ it can be built. The fact that these
extrenal helper scripts are written in perl, rather than shell or make
structures, places additional unnecessary dependencies on every package
that uses the helper scripts.

If you can insert a call to a script into the rules file, you can
certainly insert the contents of that script into the same rules file.
Either inserting the call, or inserting the code, make building the rules
file "easy" for the maintainer. The call enforces dependencies that are
not necessary, and in some cases are objectionable, while inserted code
keeps the rules file self contained and independent.

The byacc maintainer has graciously accepted my offer to provide a
debhelper-free rules file for his package, and I will be working on that
this week. I encourage anyone who has used this tool on any of the
standard packages to take steps to remove these dependencies from their

Creeping Perl

It seems that we have been allowing perl to creep into critical portions
of the installation process without resolving the consequeces of this
action. Given that we continue to have recurring discussions about
replacing bash with ash or some other POSIX sh, to reduce creeping
bashisms, why are there not more outcries against the use of perl in
installation and configuration scripting?

Look, I know that there are lots of perl programmers in the group who
think nothing of dashing off a quick perl script, but would balk at
writing the same thing in shell script. I have known apl programmers who
felt the same way about apl, but I wouldn't let them use apl for general
system construction tools either. Perl may never become a stable language,
but even if it does in the future, it surely isn't stable right now, and
should not be incorporated into critical system installation processes.

xfree86 and tetex

Although I don't see an easy way to deal with this problem, the need for
major applications packages to be in place before you can build the
primary tools for the system is very troubling. Such large apps often have
the problem, that they will not build with one of the desired libraries
(either the old library or the new one), making the transition to the new
library difficult. We have gotten past this in the past by each maintainer
"forcing" the situation in their own environment enough to build their own
package, providing the tools needed by the other packages to come into
alignment with the new library. This provides many potentials for crashing
an autobuild process, which is needed by several of the ports to "catch
up" with the Intel packages.

While I will continue to apply the "brute force" method to this problem, I
would appreciate hearing from others about ways to deal with these
problems in a more general fashion.

Waiting is,

_-_-_-_-_-   Author of "The Debian Linux User's Guide"  _-_-_-_-_-_-

aka   Dale Scheetz                   Phone:   1 (850) 656-9769
      Flexible Software              11000 McCrackin Road
      e-mail:  dwarf@polaris.net     Tallahassee, FL  32308

_-_-_-_-_-_- See www.linuxpress.com for more details  _-_-_-_-_-_-_-

Reply to: