[lsb-discuss] [packaging] LSB Package API
tytso at mit.edu
Mon Jun 30 12:47:36 PDT 2008
On Tue, Jun 24, 2008 at 07:53:16AM -0400, Robert Schweikert wrote:
> In general ISVs support more than one OS (considering all Linux
> distributions as 1 for the purpose of this discussion). The idea is to
> provide the same or similar install technology on all supported
> platforms. For this reason many ISVs use Java based installers such as
> InstallAnywhere or InstallShield that run on the supported platforms.
> For ISVs writing their own installers it is also generally desirable to
> have one interface on all supported platforms, this may be implemented
> in Java or C++ with a platform independent toolkit.
It could also be done as a shell script and a text-mode interface;
(Crossover Office does this, as does BitKeeper, for example.)
> But the interface is only one piece of the puzzle to installation. The
> second piece of the puzzle is the distribution format of binaries.
> Preferably one wants to have a format that works the same or very
> similarly on all supported platforms. Ideally the interface to this tool
> is simple and needs no auxiliary data that has to be maintained.
I think the bigger picture here is that most ISV's have their own
build systems, that have to work across multiple Linux/Unix operating
system variants, and tools like RPM have a tendency to assume that
they want to subsume the package build process. You can of course
work around RPM's "You *vill* build from prestine sources! *My* way!!
Hiel Hitler!" attitude, but it's painful, and not the way the tool is
meant to be used and most ISV's are simply not interested in great
contortions to work around Tools With Attitude.
> Last but not least the third piece of the puzzle is the privilege level
> at install time. While from a security point of view it may be a
> nightmare to have users install apps on their system it is not an ISVs
> job to prescribe a security model when it comes to installation. If a
> user wants to install the app in his/her home directory then it is not
> the ISVs installer's job to disallow such installation.
This is true, but I think that at least for now, this is out of scope
of what the LSB working group should try to solve. In the future if
there is consensus on a better non-privileged, user-homedir package
management tool, that's great, but I suspect that people need to
experiment with a number of different approaches before it's ready for
> I think this summarizes things reasonably well. Now a few comments on
> the Berlin API.
> The idea was to provide hooks into the packaging system of the
> distribution such that generic installers can provide information to the
> packaging system about what files were installed and where they live, in
> case the app was installed as root. These hooks would provide a pseudo
> integration of an ISV app with the underlying packaging system such that
> for example "rpm -qa | grep myApp" will provide reasonable data.
The way I would approach this is that this gives ISV's who are
creating their own packages an option to supplying information about
specific package names and associated files/directory names so that
(a) queries like rpm -q work, and (b) it is possible to request the
removal of a package (including running a pre-removal script) from the
native package manager interface.
If a particular package manager and/or distribution wants to take this
information being offered up by the Berlin API, and send it to
/dev/null, they can do that. It just means that users of that
distribution won't be able to use commands like rpm -q or rpm -e on
these 3rd party supplied ISV application. This is not the end of the
world if they choose to ignore this information, as it is no worse
than what we have today, and users can always choose to move to
another distribution if they so choose that provides better support
for 3rd party packaged packages via the Berlin API.
More information about the lsb-discuss