Re: Chapter 13 again ...
In message <[🔎] 200007180401.AAA32696@snap.thunk.org>, tytso@mit.edu writes
> Date: Fri, 14 Jul 2000 23:44:12 +0100
> From: "Anthony W. Youngman" <wol@thewolery.demon.co.uk>
>
> Having been advised (by private email) that the rpm thing was a FAQ,
> I've skimmed the archives, and the only thing I could find near what I
> was bothered about was "standardising the install package", a two-mail
> thread in September 1998. (The easily accessible archives don't go much
> further back.)
>
>Sigh, OK. So let's go over this, one more time.....
>
>2) There has been some talk about a RPM/dpkg format merger that has
> been underway for many months now. I don't know what it's current
> status, but we can only hope. However that turns out, the LSB is
> *not* the place to invent a new packaging format. If we did, it's
> likely that the rest of the world would probably ignore us.
And this has WHAT relevance to what I wrote? NONE AT ALL. I'm sorry, but
I took the criticism about my first post on board, and this is now a
straw man argument.
>
>5) Yes, we know that RPM's aren't necessarily compatible across
> distributions. The way that we will address this is by strictly
> limiting what dependencies a RPM can have. The only dependency that
> it can assume the system will have will be something like
> "LSB-1.0". (i.e., no libext2fs, or libc6.0, or other dependencies
> which unfortunately arne't standardized across distributions.)
> For compatibility reasons with Debian dpkg systems using aliens, we
> will also sharply restrict what kind of trigger scripts can be
> included with such RPM's.
>
This is what I was trying to address. Because you can't guarantee what
will be there, you are guaranteeing a minimal subset of out-of-date
libraries. If the LSB had been released 6 months ago, it would require
libc5, but most distros are now glibc2.1 based. If it was released today
it would require Xfree3, but in 6 months distros will HAVE to be Xfree4
based - new hardware and drivers will force their hand ... (that's
probably a slight exaggeration, but you get my drift).
In other words, as it now stands, the LSB will either act as a major
brake on innovation, or be widely ignored. I suspect it will be the
latter :-(
>
>7) Application vendors are not *obligated* to ship RPM format files.
> If they like, they can use their own tar.gz or cpio, or some other
> wrapped executable format if they like. However, given that even
> Windows 2000 has a package technology, it would be a shame if we
> were to forbid application writers from using a modern package
> management system. This approach seems to be the best, most
> pragmatic approach that is most likely to win acceptance from the
> distributions, the independent software vendors, and the users.
>
Yes. Fine. No problems there. But if I want to ship my product wrapped
up in its own installer (like Corel/WP do - they don't follow the
InstallShield herd), then as far I can see, I am hosed if I need
anything over and above what the LSB guarantees.
Let's assume for whatever reason my package *needs* glibc 2.3, and the
LSB only guarantees 2.1. As I read the LSB, *I'M*STUFFED*! If I want to
guarantee a clean install, then I have no choice but to use rpm as my
package format, and instruct the user to use their distro's default
package manager. Writing my own flashy front end to manage installing
just those components the user wants from my 3-CD package is impossible.
It may be possible to install Perfect Office 2000 from rpms using the
rpm program (or whatever), but I would be very pleasantly surprised if
such an experience was NOT unpleasant.
May I quote you on two points...
"The only dependency that it can assume the system will have will be
something like "LSB-1.0". (i.e., no libext2fs, or libc6.0, or other
dependencies which unfortunately arne't standardized across
distributions.) For compatibility reasons with Debian dpkg systems using
aliens, we will also sharply restrict what kind of trigger scripts can
be included with such RPM's."
"However, given that even Windows 2000 has a package technology, it
would be a shame if we were to forbid application writers from using a
modern package management system."
I find those two statements somewhat contradictory. I presume you don't
mean that different libc6's and libext2fs's (same rev, different distro)
are incompatible, but rather that they are not guaranteed to be present.
While I may not be going about it the right way, the problem I am trying
to address is "I need XFree4 and I need it NOW. Is it there?" If I need
technology that post-dates the most recent LSB, then I'm stuffed as
things currently stand :-( I HAVE to provide rpms, and I HAVE to trust
that the distro's default package manager will "do the right thing".
It's all very well putting "requires LSB 1.2 *and* libs x, y and z" on
the box, but firstly how many people read the documentation, and
secondly how many people would understand what it meant.
You may disagree with me, but I don't think a "guaranteed minimum
system" is that important. What I think should be addressed (and is
being completely ignored as far as I can see) is "what does this system
ACTUALLY HAVE". That latter is certainly the be-all and end-all for
bleeding edge gamers, and probably many others too. Cater for them, and
we also (at least partially) solve the problem of the LSB being obsolete
before it's finished :-) witness the recent arrival of Xfree4. We need
some way of making an installer die gracefully if dependencies aren't
satisfied, and not forcing an ISV to install "everything but the kitchen
sink" on top of an LSB base.
I'm looking at it from an "experienced user" position. I've been bitten
by a custom install prog assuming libc5 (my distro only had glibc2).
I've been bitten by a standard package manager *insisting* on installing
loads of stuff I had no use for on a relatively tiny hard drive. And I
just CANNOT see the current version of the LSB successfully negotiating
the balancing act of keeping ISVs happy, while both permitting leading
edge distros and encouraging package manager competition.
Consider the following scenario - I have a 1Gb program I'm selling. The
most recent LSB is a year old, and has been invalidated by bleeding-edge
distros :-( I want to be able do a 100Mb minimum install, and it's a
pretty safe bet a large proportion of my customers are lusers. If I
can't write a custom installer with the ability to interrogate the
system then I'm hosed :-(
Thanks to the person who told me my file layout would be slow :-) Thanks
to the person who pointed me at various threads in the archive
(unfortunately web access is a pain for me - I will hunt them up). And I
promise I WILL go away if my concerns are addressed. But at the moment I
seem to be getting knee-jerk off-target flamage :-)
Cheers,
Wol.
--
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999
Reply to: