Re: Feaping Creature-ism in core Debian Packages
On 31 Aug 1999, Manoj Srivastava wrote:
> Hi,
>
> I am confused about whether we are addressing package build,
> or package installation in this discussion. The discussion seems to
> jump back and forth suddenly -- possibly this means I am missing the
> point.
No. I just got suckered into this side discussion by someone demanding an
explanation for my perl position.
While I _do_ think that the installation process has been compromised by
the slow inclusion of additional tools like perl, that was not the
original scope of the discussion. Sorry, but I'm easily distracted ;-)
>
> >>"Dale" == Dale Scheetz <dwarf@polaris.net> writes:
>
> Dale> On 30 Aug 1999, Stephen Zander wrote:
> >>
> >> Justify this in terms of the perl-base package please. While I agree
>
> Dale> Why should I do that? Perlisms in installation scripts do not limit
> Dale> themselves to the base perl language, so saying that the base
> Dale> functionality of perl is stable isn't sufficient.
>
> If by installation scripts you mean {pre,post}{inst,rm}
> scripts, then that is a bug, since the packages must only rely on
> Base/essential packages in those scripts. If you mean intallation
> scripts as those run by ./debian/rules, never mind.
>
Personally I object to perl routines embedded in a rules file, but the
point I was trying to make is that placing perl-base in the essential
packages creates a "camel's nose" situation. Those who use perl are now
allowed to do so in installation scripts as well as in package build
circumstances. Now the stage is set for the inclusion of perlisms that
aren't supported by this essential package, but were available on the
maintainer's machine when he built the package. Now, even though you may
have the proper essential packages installed, the build fails because some
additional feature of perl is not available. The maintainer may not even
have been aware that they stepped ouside the boundries of the essential
perl package, and thus will not know to include this dependency in any
future source depends mechanism.
> Dale> It has been regularly possible to scrog the installation of
> Dale> non-perl packages that use perl scripts during installation, if
> Dale> the perl installation fails for any reason. This has happened
> Dale> on several of our past releases requiring severe work arounds
> Dale> in order to get the system back in shape. We already have the
> Dale> same possible failure point with bash, enough so that folks are
> Dale> constantly talking about replacing it.
>
> This again seems like you are talking about amintainer
> scripts. If that is the case, perl-base is essential; and yes,
> failure of essential packages can indeed scrog a system (what a
> lovely word).
(Glad you like it ;-)
>
>
> Dale> If we are going to use perl in install methods, then why not
> Dale> lex and yacc, python and tk/tcl?
>
> If you are talking about installing packages, one should
> either use a (pre-)[1]dependency, or only use essential packages
> (perl is provided by perl-base) Building make, for example, does
> require lex and yacc.
>
Actually the problem that I ran into with make (which started me down this
trail) was that it requires texi2html, which comes from the tetex-bin
package, which requires xlib6g from the xfree86 package. It was this
dependence of a core package on a large applications package that began to
cause my skin to itch.
> [1] I think if your pre-inst requires said package, it has to be a
> pre-dependency.
>
Pre-dependencies are known to kill dselect when they form a chain. (dhttp
has such a pre-depends in slink)
> Dale> The reason for not doing so is the same reason I would prefer
> Dale> to stick to shell scripts. It keeps the point of failure in one
> Dale> location where effort and care can be taken to keep things
> Dale> going smoothly. Diversifying installation scripts simply
> Dale> creates more possibilities for failure.
>
> But we already have decided on a set of Essential packages
> that can be used. There are too many things that depend on the
> Essential packages being jsut that.
Except as described above, this is not part of the problem that I am
looking at.
>
> Dale> Concrete example:
>
> Dale> I _do_ have perl, and perl-base, installed on the Ultra, yet
> Dale> debhelper, which is a perl based package building tool, will
> Dale> not build, although the pre-buildt binar-all package installs
> Dale> and works OK, as best I can tell.
>
> That seems like you are no longer talking about installation
> scripts. Well, until we have elaborated on source dependency issues,
> I am not convinced that this is a major deal.
>
Yes, I did try to drag the discussion back to the subject I started with.
Until we have elaborated source dependency issues we are vulnerable to a
catastrophic pathology in source dependencies. I don't think that it is
too early to begin considering the issues.
> A number of my packages provide HTML format documentation (by
> running texi2html). In my opinion, the advantages of the general user
> having this documentation justifies the cost of people _building_ the
> package
It only justifies the cost of building if that cost is not too high.
Consider a fundamental core program like make. Currently make will not
build without texi2html, which comes from the tetex-bin package.
Now, let us assume (probably not the case, but I need a scenerio) that
tetex-bin uses autoconf to build the source, and depends on a new feature
from the latest autoconf; but building autoconf requires the newest
version of make, which can't be built without texi2html.
Now, when you realize that to get a functional version of make doesn't
require the construction of html docs, you see that this dependency on
texi2html is "artificialy" created by Debian documentation policy.
I can comment out those calls in the rules file, and build a functional
make package, but such "corrections" are not easy to work into an
autobuild process. (Debian isn't just for Intel any more)
>
> Dale> Why are we sticking calls to perl routines into a rules file in
> Dale> the first place?
>
> To make a better package? ;-)
>
My point is that making individual packages "better" at the expense of the
overall package integration process is _not_ the path to a superior
distribution. We must begin to consider the ramifications of these
individual improvements as they pertain to the "big picture", and not
remain tightly focused solely on the optimization of individual packages.
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: