RE: Packaging stuff
-----Original Message-----
From: Theodore Y. Ts'o [mailto:tytso@MIT.EDU]
Sent: 25 October 2000 14:30
To: Anthony W. Youngman
Cc: 'Stuart Anderson'; 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 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.
Reply to: