From: "Anthony W. Youngman" <[EMAIL PROTECTED]>
Date: Wed, 25 Oct 2000 14:58:10 +0100
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 one is bogus because it claims that the only reason for using an
RPM is dependency information. There are other reasons, such as the
ability to remove and upgrade packages. Hence, the premise of Proof 1
is broken, and so the whole proof falls apart.
[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 :-(
Nope, the X libraries aren't optional. It would be nice if you actually
understood the specification before you started to attack it.
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?
A middleware which is pure vapor, and for which all of the hard
decisions have been defered, and when people have asked basic questions
like how the "protocol" would be implemented, there have been no asnwers
forthcoming?
It's not so simple. What's the packaging format for the install
program? How does the user invoke the install program? What about
dependencies for the install program itself? There's a nasty
chicken-and-egg problem right there, you know.
I can imagine this might become some kind of binary "metaconfig" like
thing, and if folks want to try to implement it, great. You'll find
there are all sorts of "interesting" problems, since library ABI
compatibility is a nasty problem. You can't just ship .o files and
relink, since Red Hat 7.0 shows that there isn't link-time compatibility
between glibc 2.1.91/94 and glibc 2.1.3. Binaries that were built
against include header files for glibc 2.1.3 won't link against glibc
2.1.91/94; that's why Oracle 8i blows up on Red Hat 7.0.
So go ahead, and try to solve the problem. I suspect you will find that
it is extremely nasty. If and when you do have such a solution, "show
us the code". And if it works and is the best technical solution
available to us, we can adopt it into LSB (1.1? 2.0? I suspect it may
take you this long. Talk is cheap.)
- Ted
