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------
