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.
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.
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.
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.
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.
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.
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.
Stuart
Stuart R. Anderson [EMAIL PROTECTED]
Metro Link Incorporated South Carolina Office
5807 North Andrews Way 129 Secret Cove Drive
Fort Lauderdale, Florida 33309 Lexington, SC 29072
voice: 954.660.2500 voice: 803.951.3630
fax: 954.938.1982 SkyTel: 800.405.3401
http://www.metrolink.com/
