Re: Chapter 13 again ... [LONG]
[Warning: Long (>= 200 lines) message (if that's not the kiss of death
for a mailing list post, i don't know what is...).]
Circa 2000-Jul-19 00:45:12 +0100 dixit Anthony W. Youngman:
: In message <[🔎] 200007180401.AAA32696@snap.thunk.org>, tytso@mit.edu writes
: >2) There has been some talk about a RPM/dpkg format merger that has
: > been underway for many months now. [...] However that turns out,
: > the LSB is *not* the place to invent a new packaging format. [...]
:
: 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.
This may not appear to relate directly to what you wrote. It is,
however, part of the big picture. In short: LSB does not wish to
invent a new packaging format. It attempts to specify existing
practice where available. In the case of packaging format, the
specified practice is the RPM package format. As Ted points out, this
does not necessarily mean the 'rpm' command or the RPM package
database. As long as the local package management system provides the
LSB-specified interface and reads the LSB-specified package format,
everything's peachy.
: >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.
Excuse me? At a face-to-face LSB meeting in New York six months ago,
the question was whether to specify the ABI available in glibc-2.1, or
to wait for the ABI in glibc-2.2. To my knowledge, LSB has never
considered the libc-5.3.x nor the libc-5.4.x ABI.
: 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).
You seem to be missing the point of LSB. LSB explicitly does not
specify XFree86-3.x or 4.x, or glibc-2.x, or libcruft-8.0. LSB
specifies APIs, ABIs, and behaviors (much of which is taken from other
specifications such as POSIX, SUS, etc.). As long as distributions
provide the necessary libraries, commands, etc. to provide the
specified functionality, they're compliant. Ted points out (or if he
doesn't, he should have:) that the LSB package management commands can
easily be a wrapper around 'alien' (if needed) and the native package
manager. Same with other things, as long as they provide the specified
functionality.
: 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 :-(
Actually, if folks would stop insisting on rehashing old topics, i
suspect that the LSB would be completed soon, and that it would soon
thereafter enable independent software vendors to provide installable
packages that would work across all LSB-compliant distributions, rather
than having to build variant packages for each supported distribution,
as many do now.
: >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.
If your software requires functionality that is not provided by the LSB
specification, and that your software itself does not provide, your
software is not LSB-compliant, and you can do anything you like.
You'll simply have to use distribution-dependent methods to determine
what functionality is available and install your software.
: 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*!
Nope. If your software depends on an API that's not specified by LSB,
you have several choices:
(a) Link the required libraries to your binaries statically. Your
software is still LSB-compliant (as long as it doesn't violate
the spec in other ways, such as by using kernel system calls).
(b) Install the shared library you require in an area specific to
your application, and cause your application to look there for
shared libraries before linking with system libraries. Your
software is still LSB-compliant (again, as long as it complies
with the spec in other ways).
(c) Use a copy of the libraries provided by the distribution your
software is meant to be installed on. Your software is not
LSB-compliant.
Option [c] is no different than things are now.
: If I want to guarantee a clean install, then I have no choice but to
: use rpm as my package format,
(Recall that the RPM package format is distinct from the 'rpm' package
manager software)
: and instruct the user to use their distro's default package manager.
If you're distributing LSB-compliant software, you should either:
(a) Instruct the user to use the LSB package management commands to
install your software; or
(b) Provide a front end which itself detects and uses the LSB package
management interface to install your software.
: Writing my own flashy front end to manage installing just those
: components the user wants from my 3-CD package is impossible.
On the contrary, quite possible. In fact, with LSB, you'll only have
to write one flashy front end for your software that will work on all
LSB-compliant distributions, instead of having to port the front end
between differing distributions.
: May I quote you [meaning Ted] on two points...
:
: "The only dependency that it can assume the system will have will be
: something like "LSB-1.0"[....]
:
: "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.
See what i wrote above. If it's not in the LSB spec, the ISV is
required to provide and install it along with the application.
: 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 :-(
Nope. See above.
: I HAVE to provide rpms, and I HAVE to trust that the distro's default
: package manager will "do the right thing". [...]
If your software satisfies all its own non-LSB dependencies, the LSB
interface to the local package manager will in fact do the right thing.
: You may disagree with me, but I don't think a "guaranteed minimum
: system" is that important.
As an employee of an ISV, i do disagree with you, vehemently. Have you
ever tried building and packaging software so that it works under Red
Hat, SuSE, OpenLinux, TurboLinux, Slackware, CorelLinux, Debian, and
Mandrake (and maybe even the Linux emulation environment of FreeBSD)?
It's a nightmare, even though five of those eight (nine) systems use
both the RPM package format and the 'rpm' package management software.
: What I think should be addressed (and is being completely ignored as
: far as I can see) is "what does this system ACTUALLY HAVE".
We already have that. Thrice over. With LSB, the software says "I
require LSB version 1.0," to which the package manager replies, "The
system provides LSB version 1.0, you're clear to install."
: 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 :-)
LSB is not intended to be a partial solution. It's intended to be a
complete set of APIs, ABIs, and behaviors on which compliant software
can safely depend. The additional problem of how to ensure that APIs
and ABIs remain compatible across versions of major system libraries is
not one that LSB is intended to solve directly.
: 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.
If your software has a significant number of dependencies on
non-LSB-compliant libraries, you'll have a rather large software
package to install. There are two ways around that:
(a) Don't expect your software to be LSB-compliant.
(b) Reduce the number of non-LSB dependencies in your software.
: 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.
LSB-1.0 is not particularly intended for tiny hard drives. Depending
on your system, though, an old, obsolete 4 or 6 GB drive ought to
suffice.
: 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.
As Ted mentioned above, the leading package managers themselves are not
striving for competition, but rather for compatibility and
interoperation. Don't confuse "evolution" with "competition".
Recall also that b?le[ae]ding edge distributions ought to have no
problem remaining LSB-1.0 compliant, as long as they provide the proper
combination of APIs/ABIs/behaviors. LSB doesn't care, and doesn't care
to limit, what else such distributions provide. Recall that many
currently available glibc-based distributions still provide support for
libc5 binaries; how does that backward-compatibility put a brake on
innovation?
: 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 don't see how the LSB could be invalidated by a b?le[ae]ding edge
distribution, unless the distribution decided not to provide the LSB
facilities. The LSB is *intended* to be a stable development target
and operating environment, not a constantly changing one. (This is not
to say the LSB will never be updated, only that it's not likely to
change at the drop of a hat. This is a feature, not a bug).
: 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 :-(
True. The LSB doesn't keep you from doing that. As an ISV, you may
either:
(a) provide your software in a set of one or more LSB-compliant
packages, with an LSB-compliant front end that uses the LSB
package management interface to install your software; or
(b) provide your software in multiple sets of one or more packages,
one set for each variant distribution you wish to support, with
one or more front ends that use each distribution's native (or
your own) package management system to install your software.
Option [b] is the same as things are now. The LSB isn't preventing you
from doing anything you can already do.
: 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 :-)
Nick Petreley recently (or is it not-so-recently, now?) joined up with
things in medias res. He may know of helpful resources to get you up
to speed. His address is liable to be in either the lsb-spec or
lsb-discuss list archives somewhere.
--
jim knoble | jmknoble@jmknoble.cx | http://www.jmknoble.cx/
Reply to: