Re: Standardizing the install Package...
Hi everybody,
I would like to point out the following wrt to package installation
and management: from the administrator's point of view, having *passive*
packages may be more comfortable. By passive, I mean a package whose
installation consists of placing files in the proper places: no scripts
are run. I have been a fan of RPM until scripts and triggers have been
introduced; now I make a point of inspecting the package scripts before
installing something (which limits the usefulness of excellent tools
like Kirk Bauer's AutoRPM).
The problem with scripts, of course, is that they are programs and as
such give you plenty of rope to hang yourself with but, unlike most
programs which are run by a user and just terminate on error, have a
chance to screw up your system (and run as root). I am not discussing
security here, although it might become an issue: I dread well-meaning
installation binaries (in a binary-only system, I fear we'll have
installation binaries) which go fumbling around in /etc because
otherwise the binary-only program does not work.
This is especially important, IMHO, in the context of the LSB, where
the intent is to estabilish a standard for binary-only packages. For
open source distribution, fixing a bug in a script embedded in the
package is just another release, but a binary-only vendor might be
tempted to tell the customer it is *his* linux system which is not
standard - this might also complicate upgrading to a newer release of
your favorite distribution, or limit the distributors' freedom to make
changes in view of compatibility with established binary packages.
What I suggest is that the introduction of binary-only packages,
especially from vendors not accustomed to Unix, should be made having
abundantly clear that your package is not "the application" but "just
another tool" which must make every effort to fit in the system and
provide enough flexibility to let the user help it to fit where it
cannot manage on its own, not adapt the system to the application as MS
installers do.
Summary: I think the LSB standard package format should be completely
passive and should not allow any kind of scripting (not arbitrary shell
scripts, nor, heaven forbid, an embedded scripting language like .INF
files) for binary-only packages. If an existing standard is settled on,
say RPM, this should be documented as a semantic restriction preventing
LSB compliance.
A question: if package A depends on B and B is not in the system, what
is the standard behavior: (a) echo "I need $B" and fail; (b) carry
around anything you might need and install it silently; (c) not
standardized, do as you please ?
Davide Bolcioni
--
#include <disclaimer.h> // Standard disclaimer applies
-----BEGIN GEEK CODE BLOCK-----
Version 3.1
GE/IT d+ s:+ a C+++$ UL++++$ P>++ L++@ E@ W+ N++@ o? K? w O- M+ V?
PS PE@ V+ PGP>+ t++ 5? X R+ tv- b+++ DI? D G e+++ h r y?
------END GEEK CODE BLOCK------
Reply to: