Packaging stuff

[Anthony W. Youngman]

In message <Pine.BSF.4.21.0010241052520.468-100000 at trantor.sc.metrolink.
com>, Stuart Anderson <anderson at metrolink.com> writes
>
>
>If everyone will read the specification carefully, you will note that it
>specifies RPM for lack of a better suggestion. That is a challenge for someone
>to come up with a better suggestions. A few things have been mentioned, but
>nothing has really been offered as a proposal (no offense to those that
>have made suggstions).
>
>In order to be a viable proposal, there needs to be a formal specification,
>and implementation, and some way to test it. So far, no one has presented
>any of this.
>
>We have discussed the merits & shortfalls of RPM vs the Debian method, and
>I think a couple of people were going to go off and try to resolve the
>differences, and present an implementation, but they were never heard
>from again.

Because they were slapped down? That's how I felt after my attempt :-( I
just gave up in disgust ...
>
>The people working on the LSB are completely saturated, so something of
>this magnitude needs to be developed by someone else. Preferably people
>involved with the distributions that have to adopt it.
>
>
>Now, on to what needs to be standardised.
>
>First the format of the file that represents the package needs to be
>standardized. In other words, the thing that you download or read off of
>a CDROM.

Why?
>
>This file has to contain some number of files, and other information.
>It will likely contain a set of special files that are used during the
>package install/removal process. Nominally, this will be pre-install,
>post-install, pre-remove, and post-remove scripts.
>
>What commands can be used by these scripts needs to be specified. The list of
>available commands in the LSB covers this.

Start thinking "out of the box". You are stuck in the mould of what's
already been "sort of" specified. Why not take a completely new tack?
>
>Where the files that are part of the package can be installed needs to
>be specified, this is covered in the FHS.
>
>How dependencies are described needs to be standardized. There is a single
>dependency for the LSB base, but large applications may need to be broken into
>several package, so dependencies among the package need to be specified.

Yup. A standard namespace, and a standard api for accessing the
distribution-specific package database.
>
>What does not need to be standardized?
>
>How the installation tool works does not need to be standardized. Only the
>command for invoking it needs to be specified.

IE a standard API!
>
>How the dependencies are maintained does not need to be specified. Only the
>fact that the tool can compare the dependencies in a package vs the list
>of what is on the system is required.

Yes Yes Yes!
>
>How the backend database is implemented does not need to be specified. It is
>up to the tool that is provided to manage the backend DB.
>
>
>
>It would be far more helpful if concrete proposals were offered instead of
>complaints.
>
I DID TRY!

Maybe if Nick and me get together and bounce some ideas we might come up
with something. The only thing that appears won't go down well is that
we will DEFINITELY ditch the idea of "the standard package format is
rpm". To both of us, this appears to be totally orthogonal to the
problem at hand.
-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports 
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999