-----Original Message----- From: Theodore Y. Ts'o [mailto:[EMAIL PROTECTED] Sent: 25 October 2000 16:45 To: Anthony W. Youngman Cc: 'Theodore Y. Ts'o'; Anthony W. Youngman; Nicholas Petreley; [EMAIL PROTECTED] Subject: Re: Packaging stuff
From: "Anthony W. Youngman" <[EMAIL PROTECTED]> Date: Wed, 25 Oct 2000 16:27:01 +0100 Yes - but in order to upgrade and/or delete you need the dependency information. And I did say that proof one addressed the problem of getting the software ONTO the system, thereby explicitly excluding getting it off (deletion or upgrading) You don't need dependency information to upgrade or delete an LSB-compliant application. That's the whole point of the restrictions we place on what a LSB 1.0 compliant RPM-formst must look like. [awy] in other words, an LSB-compliant application *must* be completely self contained for anything over and above the LSB. So if several apps all use the same library, there will be one copy on the system for every app :-( Waste of space, waste of memory. But I am now beginning to grok the vision, and understand *why* you're doing it. But if that's true, why on earth do you need an rpm? A tgz or self extractor that contains a ./Runme (aka WordPerfect 8) will do fine. Maybe the self extractor could fire off the ./Runme and package format becomes irrelevant - just guarantee that tar and cpio will be available for the extractor if it wants them. If the libraries are there, chapter 13 becomes irrelevant and can be ignored. pre- and post-install etc become the responsibility of the ./Runme [/awy] (Note also that we don't force ISV's to use RPM's. In some cases, database vendors already have their own very complicated installation programs and .tgz files, and if they want to use them, that's their progative. It means that users won't be able to do an easy uninstall, but that's their business.) [awy] Actually, I think that's going to come back and bite you, as well as them, but never mind... have you ever installed a complicated database, that *needs* to stuff daemons, libraries, runtimes in all the relevant places? You may well have, I certainly have, and I think the LSB's approach might be a tad too simplistic here... surely a database server will NOT be LSB compliant, because the admin will have installed it headless without X - or are you expecting us to emulate the Windows habit of buying overspec'd hardware in order to install software we have no use for :-) [/awy] But please, I'm trying to understand your vision. And everywhere I see logical flaws. By all means look at mine and point out the flaws to me. But don't use an argument about deleting files, to attack a place where I'm adding files. Are you? If you're really trying to understand, why don't you try to read the specificaiton, and look at some of the history of the mailing list, instead of simply attacking the LSB and then waiting for us to defend it. That takes a lot of time, and I don't have a lot of time to waste. If everyone used this method to learn, we wouldn't have time to actually spend doing anything useful. [awy] I have read it. It is extremely dry. [/awy] The fact that you thought the X libraries were optional, and defended your ignorance on the grounds that no one had bothered to correct your attacks based on that ignorance, doesn't speak much repsect for the collective time of the group of people who have been working on the LSB. [awy] I'm not sure where I was told that, but as I understood it, there would be several levels of LSB compliance - the base level being a minimal install and then more levels being added on top, eg 1 guarantees glibc2.2, 1.1 guarantees 1 + X, etc etc. May I make an extremely serious suggestion? I really expect it will help clean up a lot of these wars if you take it up? At the start of the LSB document itself, preferably in front of the index so it is the *FIRST* thing a casual browser stumbles over, there should be a "Political PreRamble" a bit like the GNU manifesto that is *part* *of* the GPL. In that, you should lay out what you are trying to achieve, and why. And a major reason for that is that the name "Linux Standard Base" is ambiguous. As a result of various emails (some private) I now realise that what you are aiming for is a ' Linux "standard base" '. But the general view "on the street", as far as I can tell, is that you are aiming to be the ' "Linux Standard" base '. If you can understand that confusion (and the best place to address it IS a manifesto at the start of the LSB document), then you will be well-placed to contain and correct further confusion. That doesn't alter my belief that you are aiming for a limited objective, and as such run a very serious risk of disappointing everybody and pleasing no-one. But at least I understand *why* you are doing it, and *what* you are trying to achieve. I almost certainly *will* try to come up with an improved version of my idea (which I hope would make it into LSB 2.0). And while I don't want to say "oh I'll do it easily", I view package management as a database problem (of course), and by profession I am a database programmer. So maybe I do stand a decent chance :-) 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.
