-----Original Message----- From: Theodore Y. Ts'o [mailto:[EMAIL PROTECTED] Sent: 25 October 2000 14:30 To: Anthony W. Youngman Cc: 'Stuart Anderson'; Anthony W. Youngman; Nicholas Petreley; [EMAIL PROTECTED] Subject: Re: Packaging stuff
From: "Anthony W. Youngman" <[EMAIL PROTECTED]> Date: Wed, 25 Oct 2000 12:36:08 +0100 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. Correct. 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)? Customers do want to be able to easily *remove* and *upgrade* packages. cpio and tgz doesn't provide this capability. Even Windows users have this capability, and compared to .rpm or .deb's, or Windows 2000 packages, cpio or tgz are a very sad, out-dated technology. [awy] Except that you have just missed the point of proof 1 completely! Proof 1 is ORTHOGANAL to the problem you've just cited, therefore your argument is irrelevant. You should have addressed this at proof 2. [/awy] 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. The scope of LSB is specifically for third party manufacturers. I.e., what Loki needs to ship Quake, or Intuit needs to ship TurboTax for Linux. Yes, this is a restrictive scope. But Nick (and others) have criticized the LSB effort for taking so long. Trying to expand the scope, and revisiting decisions which were already made, is not a method calculated for shorting the time period before LSB 1.0 can get out. Since this is *all* we're trying to do, and we can affect what the application vendors do when they create their package, all we need to do is tell the application vendors what they can depend on, at which point the only package dependency is needed is one for "LSB 1.0". [awy] Except that X will be optional in LSB 1.0 as I understand it, so the LSB is useless to all vendors shipping gui products, ie most of them :-( And yes, I do agree with the "show us the code" premise, but when I feel that the current argument is built on sand and false logic, then I have to argue with it. If your foundations are screwed then there's no point in building a wonderful house on top, because it's all going to collapse at the slightest stress. "All we need do is tell the application vendors what they can depend on" - and if they happen to depend on something not in that list (like X) then do they have to install it themselves? If the LSB does not guarantee to meet my dependencies, and provides no way of telling me that those dependencies are met, then I'm going to ignore it. I don't, actually, have any other option! And anyway, which is more minimalist and likely to be followed? A specification which lays down file types, and an absolute list of supported of features, or a middleware which allows ANY install program to query ANY package database and make intelligent decisions on the responses therefrom? And as for "expand the scope, and revisiting decisions which were already made", why has the relevant section not been expanded beyond its very primitive draft phase? Yes it has changed slightly recently, but not much. Surely the effort to spec a proper middleware interface is no more than the effort required to complete the spec as it stands (or has nobody tried to complete it because it's a damn sight more difficult than it looks?). Cheers, Wol. 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.
