Re: Feaping Creature-ism in core Debian Packages
On Wed, 1 Sep 1999, Aaron Van Couwenberghe wrote:
> On Mon, Aug 30, 1999 at 03:44:08PM -0400, Dale Scheetz wrote:
> > Why are we sticking calls to perl routines into a rules file in the first
> > place?
>
> Because vanilla sh using only calls to dpkg-deb for packaging purposes gives
> me a sour stomach. Really, why do something so massochistic when a similar
> makefile using debhelper requires 10x less code?
Sorry about your sour stomach, but to me, one language is usually as good
as another, as long as there is symmetry and completeness to the
instruction set.
Staying within a fixed set of fundamental tools _is_ good integration
design.
>
> Is it OK for us to be lazy if that laziness allows a source depend on a
> *core* item to become somewhat common? You speak of perl's instability, but
> source builds aren't exactly as crucial as package installations, and many
> fairly important packages pre-depend on perl. Is this heretical?
>
Well, first of all, source builds _are_ crucial to package installation.
Without the ability to build source, you have no package to install.
Having a subset of perl in the base system is part of the cause for perls
apparent "instability". The fact that you can pre-depend on this limited
perl, and use perl in the package build, opens the door to the use of
non-supported-by-base-perl instructions in the package build. Because the
maintainer is a perl buff, and has all the perl extensions and libraries
installed, he never notices the slight "creep" away from the designated
features of the tool set.
I don't object to perl, any more than I object to any other package. I
just think that we are being way to relaxed in our treatment of the
complex interconnectedness we are creating with these indeterminate source
dependencies.
> If I were in your shoes I wouldn't care about the perl dependency, but the
> texi2html dependency. This is the less urgent. But there's another problem
I'm not concerned specificly with any one dependency. It is the
uncontroled expansion of those dependencies in ways that haven't been
looked at closely enough that worries me about these situations.
> assuming you propose at-package-installation document translation: you've
> just added a gamut of pre-depends to almost all complex packages. This will
Not any more than the menu system has done, which is none. No package
would need to depend on the translation tools. Only the viewer packages
(dwww and friends) would need to depend on them, and only the viewer would
need to update any outstanding translations. The individual packages would
register the information in a pre-defined location. If the viewer's
translation routine is found in post install the individual package runs
the translation routine itself. If it isn't found, the information is
logged for the viewer to translate when it _is_ installed. This method
keeps the build independent of the translation tools and viewers, while
providing the proper document integration at installation time.
> certainly miff some Debian users. In addition, document translators are
> often more finicky about their environment (phase of the moon, minor
> version...) than perl.
Which is why the document translation should be managed by a set of tools
designed for that task, and not by each and every individual package in
its own specialised fashion.
>
> On a side note, I've come across a number of packages that (seemingly)
> needlessly declare a dependency on X; maybe I just haven't researched the
> situation. However, it seems to me that with sufficient twiddling, tetex
> could stop depending on the base X libs.
>
Memory says that the xlib6 implimentation was a solution that kept
packages from needing to incorporate all of the X libraries just to be an
X aware program. (You can't tell where you are executing without some
hooks into X for a display check)
For build purposes, it would be very nice to be able to build only the
xlib6g and xlib6g-dev packages from xfree86, but I fear this will require
extensive redesign of the source build process. While I don't see that as
a bad thing, it looks mighty intractable under Debian's current design
process. I guess what I have been asking in this thread is that we take a
much closer look at all of our "accepted" practices with an eye focused on
how these practices effect the overall integration of packages into a
cohesive system. Without such a determination, the integration problem can
grow into an N squared problem (where N is the number of packages), and we
may find ourselves in a circumstance where we can never get to a release
date just because the closure rate on successfuly integrating all the
packages may drop to zero before we get to a releasable state. This is
where my concern lies, and not with any one package "getting in the way".
Luck,
Dwarf
--
_-_-_-_-_- 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: