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:[EMAIL PROTECTED] Sent: 24 October 2000 23:44 To: Anthony W. Youngman Cc: [EMAIL PROTECTED]; 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 [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/ 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.
