RE: Packaging stuff
-----Original Message-----
From: Theodore Y. Ts'o [mailto:tytso@MIT.EDU]
Sent: 25 October 2000 16:45
To: Anthony W. Youngman
Cc: 'Theodore Y. Ts'o'; Anthony W. Youngman; Nicholas Petreley;
lsb-discuss@lists.linuxbase.org
Subject: Re: Packaging stuff
From: "Anthony W. Youngman" <Anthony.Youngman@ECA-International.com>
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.
Reply to: