RE: Packaging stuff
I'm interested to hear about the command interface - I'll have to check the
copy of the LSB and confirm whether it's been updated and whether it's
there.
As for API I think of it as "middleware", regardless of how actually it's
implemented.
I think I've actually posted a form of this already but I've now thoroughly
formalised my objections to rpm et al. (Seeing as this mail-id isn't
subscribed to lsb-discuss the post there may well bounce, so feel free to
forward it to the list if that's the case.)
AIM: The aim of this section of the LSB is to ensure that a package is
guaranteed to INSTALL AND RUN on an LSB-compliant system. To that end we
have two orthogonal problems, getting the package onto the system, and then
to install that package such that it will run successfully.
PREMISE: I hereby argue that the rpm file format is the wrong way of
achieving either objective. The problem/confusion is caused because the
existing LSB documentation says "we will use a suitable subset of rpm", thus
implying that we are tackling both problems at once.
PROOF 1: To achieve the first objective, placing the files onto the system
in question, we do not need any dependency information. To this end we
should strip all dependency information from the rpm. This reduces it (as
far as I can see) to a pure cpio archive, so why on earth aren't we using
cpio (or tgz)?
PROOF 2: To achieve the second objective, we need dependency info, and a
package management database. The LSB *studiously* *avoids* trying to address
this problem, thereby making it impossible to guarantee that a program will
install successfully and run. The format of the archive file that is
delivered onto the system is irrelevant to this problem, so rpm is
irrelevant. And if you specify dependency information in the rpm the LSB is
laying down exactly the restrictions it is trying to avoid.
I respectfully argue that the specification (as at when I last looked) is
internally inconsistent, doesn't work (as Nick pointed out with ncurses),
and should be completely rethought. Please note that the above critique is
meant to be a mathematical proof! It may be poorly worded, but if you wish
to argue then you need to understand what I'm getting at, and point out
where I've cocked up in my "if a then b" thinking, not just say that you
don't like it. You MUST separate the two aims of "placing the package on the
system" and "getting the package to run". Because if you don't you will fall
right into the middle of all these arguments and wonder why they keep
flaring up.
Nick - look at my original Chapter 13 post in the archive, and you'll see
why and how I was trying to achieve a *simple* system that allows *anyone*
to write a program installer and be able to pretty much *guarantee* either
that it left the package in a usable state, or that it failed with a clear
explanation of the problem. And the reason I'm screaming at the LSB is that
I feel it is not trying to address this problem.
-----Original Message-----
From: Stuart Anderson [mailto:anderson@metrolink.com]
Sent: 24 October 2000 23:44
To: Anthony W. Youngman
Cc: lsb-discuss@lists.linuxbase.org; Anthony W. Youngman; Nicholas
Petreley
Subject: Re: Packaging stuff
On Wed, 25 Oct 2000, Anthony W. Youngman wrote:
> Okay. I'm quite happy to have a go at specifying something. I'll almost
> certainly need some help, though. It's just that last time I tried, as
> mentioned before, I felt rather "slapped down". I bet Nick will help.
Check with George. He is trying to keep the list of what needs to be
written.
The improved database will soon make it easier to look and see what needs
doing, but but there is still a bit of work left before that is fully "in
production".
> Not necessarily a C interface (though that would be nice). Basically a
> standard naming convention, and some form of query/update language that
> says "does package X exist" or "I've just installed package Y". So yes,
> an "lsb --query, lsb --install, lsb --delete" sort of api might well be
> in the works.
I think we have already come up with this command interface. If it isn't in
the document already (and I'm assuming it isn't since we're having this
conversation 8-)) then we need to fix that.
> The idea is that the LSB contains an api, and it's the package database
> guys (eg the RedHat guys who maintain the rpm program or the Deb guys
> who look after apt) to actually write the interface that queries their
> database.
Yes, I think we have been violently agreeing on this part, but a difference
in terminology has been confusing things. When I see API, I think of a C
library interface. I suspect that other also had this misunderstanding.
A command interface provides a higher level interface, which is generally
desirable.
Stuart
Stuart R. Anderson anderson@metrolink.com
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/
This transmission is intended for the named recipient only. It may contain
private and confidential information. If this has come to you in error you
must not act on anything disclosed in it, nor must you copy it, modify it,
disseminate it in any way, or show it to anyone. Please E-mail the sender to
inform us of the transmission error or telephone ECA International on +44
(0)20 7351 5000 immediately and delete the E-mail from your information
system.
Reply to: