RE: Packaging stuff
-----Original Message-----
From: Theodore Y. Ts'o [mailto:tytso@MIT.EDU]
Sent: 25 October 2000 15:53
To: Anthony W. Youngman
Cc: 'Theodore Y. Ts'o'; '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 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]
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)
As for easy upgrade/removal of windows - I gather that relies on the
installer installing an uninstall package and registering in the registry -
it's a bit more sophisticated than that but simply requiring the package to
include an unistall script would implement most of Windows functionality :-)
[/awy]
[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.
[awy]
Okay, fine. I was led to believe (and have publicly stated that I believed)
they were. Why didn't anybody correct me earlier? So we have now excluded a
large number of small systems from LSB compliance (though I doubt whether
the owners could care less).
[awy]
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?
[awy]
bear in mind I'm not on the list right now - I'm seeing what's cc'd to me at
work, so if those questions have just been asked I won't have seen them. If
they were asked some time ago and I had seen them, I would have had a go at
answering them.
[/awy]
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.
[awy]
The same chicken-and-egg as "how do you get linux onto a system that's never
run it before". The distro is entitled to enforce the package database and
default package management program. If the install program needs to install
itself, then it is not allowed to have dependencies, ie it must be
statically linked (or be specific for the distro). I can't see that being a
hardship.
[/awy]
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.
[awy]
I know. And if you go back to my earlier writings, I forsaw and tried to
address this problem even before RedHat 7.0 showed it up so obviously! If my
predictions are borne out dramatically by events shortly after then it
doesn't prove I'm good, but it provides evidence towards that conclusion.
[/awy]
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.)
[awy]
I know it is. Which is why I tried to do. And the general reaction was that
people weren't even prepared to TRY to understand the problems I saw.
And I still see them. If the LSB lays down a specific set of supported
facilities, then it is providing a specific solution to a generic problem.
Looked at through engineering eyes this is an arse-over-head botch-fix and
guaranteed to fail in the long run.
What I want is simple. I want the distro to specify the package database
format. I want the user to be able to specify his installer of choice. And I
want the installer to be able to query and update the database, ie I can run
rpm and it will update my debian package database, or I run apt and it
updates the RedHat package database, or whatever. I DO NOT see the current
spec encouraging that.
I'll go away. I'll work on my spec. And I'll try and make it possible for
Corel to write their own custom installer for WordPerfect 8 that will be
able to query my package database and realise that I don't have libc5,
rather than just crapping out all over the place without warning because I
didn't realise my distro had left it off the CD.
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.
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: