Re: [Lsb-CommonPackaging] Re: extension of lsb packages
On Wed, Mar 06, 2002 at 08:10:19AM -0000, Anthony W. Youngman wrote:
> Which is why I'm trying to get a new standard that says "here's an api. With
> this, ANY packaging program can talk to ANY distro package database and
> query it".
>
> Bingo. All packaging problems solved. You can run any installer on top of
> any distro and check dependencies, log the fact that you've installed stuff,
> etc etc. The trouble with current install mechanisms is that they are
> installer, DBMS, packager, and god knows what else all stuffed into one
> bundle. If we separate the separate functions into separate tools like all
> good linusers do, then the problem gets a lot simpler.
If you assume that the packaging system is responsible for installing
packages, then it isn't that hard. You just simply have a couple of
operations, really:
1) /usr/lsb/lib/install_package <package_file>
2) /usr/lsb/lib/remove_package package_name [version]
3) /usr/lsb/lib/query_package package_name [version]
Of course, then the only reason why you need a fancy installer program
is to allow the user to choose which sub-packages the user wishes.
If you're thinking more in the Windows model, where each vendor has
their own propietary setup.exe program which is responsible for
copying files in, then that becomes a horse of a very different color.
You need to realize that (a) the packaging system keeps track of which
file is owned by which package, and often keeps a checksum information
about files, so it can determine if a package has been corrupted, (b)
it's kinda stupid to have each vendor replicating the code to copy a
file into a standard location, and (c) the API between the installer
program and the packaging system gets *very* complicated, because of
the need of the installer to report where each file is to be installed
first.
It also doesn't solve any of the hard problems of packaging, which include:
1) Packaging namespace. Each distribution assumes that it, and only
it, controls the namespace of packages. So they will freely create
packages without worrying about collisions.
2) Version numbers. Each distribution uses a versioning scheme which
is roughly related to the original upstream author's versioning
scheme, but there are both "epoch" numbers which are more significant
than the base version, as well as "release" numbers which are less
significant than the base version.
3) Incompatible event models for installation and deinstallation and
upgrade scripts. The pre- and post- install scripts can be hand-waved
away if you assume the propietary, hand-written installation program
for each package. (Although this clearly wouldn't scale for the
several hundred packages in a base distribution, but we'll ignore that
point for now). However, how and when the scripts which get run when
the package is deinstalled or upgraded *do* need to be standardized,
since the installation program won't be running at that point.
4) Detailed configuration information for each base package to be
provided by the distribution. The FHS provides general guidance to
the distributions, but there are all sorts of details about how Apache
is to be configured, or what the precise directory name is used in
/var/lib, which do differ from distribution to distribution.
5) Knowledge of how to modify system configuration. If a package
needs to add a port to /etc/services, how should it do so such that it
will survive an update of the base distibution? How about
/etc/inetd.conf? Etc.
All of these combine to make the problem of dependencies very, very,
hard. If my program needs to be able to send mail, what package (or
virtual package) do I need to list in my dependencies to guarantee
that exim or postfix or sendmail will be installed?
What package do I need to depend upon to guarantee that Apache will be
installed. And if my package is providing an Apache plug-in module,
where has the distribution decided to place the standard Apache
plug-ins? For that matter, where has the distribution decided to
place the Apache configuration files? Or log files?
And if my package requires at least Apache 1.3.12, how do I state
that? Different distribution may have different epoch numbers, and in
some cases, different ways of encoding the version number if the
upstream author hasn't been careful about releasing software with
consistent version numbers.
So to say, "all we need to do is to specify an API", and like pixie
dust, expect that all of the hard problems of packaging will just
magically disappear, is a bit naive.
The LSB 1.0 has a partial solution to these problems, but we do so by
significantly constraining what an LSB-compliant package can do. An
LSB-complaint distribution can only depend on a single package, named
"lsb". We restrict what sort of things the package is allowed to
assume (because they're different on various distributions). We
require long package names, such as "lsb-quicken.com-turbotax", which
are not universally popular.
> Of course, the fly in the ointment is this becomes a "standard creating"
> exercise, rather than the current "codifying existing standards" exercise
> and there'll be horrendous politics. But if you think about it, the proposed
> approach will work perfectly, even with an ISV who wishes to create a
> totally proprietary, obscured to the hilt, 100% totally self owned code,
> setup.exe to run on a lsb-compliant system, AND IT WILL WORK. If we can
> address and allow for that setup, it then makes it easy for every one else
> to be far more sharing and co-operative.
Well, ask yourself this. What parts of a propietary, obscured to the
hilt, hand-rolled installer would the ISV really want to keep secret?
And why? Copying files around? That's not secret. The list of what
files are installed? We can compare the system before and after the
installation, and know what files where installed/modified.
The only thing which really needs to be kept secret/propietary is the
initial configuration of the package, and arguably that shouldn't be
part of the installation process in the first place. You *want* to
separate that out, and perhaps the most you should do is to be able to
call the initial configuration tool from the post-installation script.
The bottom line is that I don't think there's any real value in having
a windows-style SETUP.EXE custom installer. People may be accustomed
to it because it's what Windows used to do, but even in the newer
Windows system, Microsoft has actually been moving to the packaging
model used by Linux distribution systems, where the vendor provides a
package, and the packaging system takes care of installing it.
Indeed, with Windows 2000, Microsoft was boasting about how for the
first time, they can verify whether or not a package has been
corrupted or not --- of course, they conveniently failed to mention
that Linux and its packaging systems (especially RPM) has been able to
do this for years....
- Ted
Reply to: