LSB Package API

Submitted by Jeff Licquia on Mon, 06/23/2008 - 20:46.

[Commenting on this thread is a disaster; different people strip off different mailing lists, and parts of the conversation are happening everywhere. Can we all agree, at least, to keep the packaging list in followups?] Richard Hughes wrote: > Being blunt, no distro is going to support a LSB package API. In 2006, representatives from Red Hat, SuSE/Novell, Debian, and Ubuntu committed in principle to doing just such an API once it was done. Of course, that's not a guarantee, but it holds a little more weight, I think, than the above quote. At that 2006 meeting (December, in Berlin, thus the "Berlin API" name), these representatives from the distros were told by numerous ISVs why distro package systems were not acceptable. The Berlin API was a compromise; the idea was that third-party software installers and package managers would be able to communicate and cooperate. Part of the issue may be that most of the implementations so far have assumed that communication from a third-party installer would result in a pseudo-package being registered in the native package database, which leads people to believe that this is a "new package format" of some kind. The original idea, though, was for a communication protocol only. The native package manager may decide to store the results by creating a pseudo-package, but does not *have* to. I think we're willing to accept that the particular implementations of the Berlin API idea are wrong-headed, and perhaps re-do them. But the general idea--accepting that things such as InstallShield and InstallAnywhere are going to exist, and finding a way for them to cooperate with the underlying system instead of fighting with it--isn't something I see anyone else trying to address.

[packaging] LSB Package API
Submitted by dank on Mon, 06/23/2008 - 21:30.

On Mon, Jun 23, 2008 at 1:43 PM, Jeff Licquia wrote:
> At that 2006 meeting (December, in Berlin, thus the "Berlin API" name),
> these representatives from the distros were told by numerous ISVs why
> distro package systems were not acceptable.

I looked around for details, and though I found summaries,
https://lists.linux-foundation.org/pipermail/packaging/2007-January/0003...
http://www.linuxfoundation.org/en/LSB_face-to-face_(December_2006)
http://ianmurdock.com/2006/12/19/software-installation-on-linux-tomorrow...
I didn't find anything that really enlightened me about
the situation of the ISVs who are locked in to existing proprietary installers.

From what I can gather, the story is "We (e.g. SAP) already have
our installer, thank you very much. And we don't want to change it.
We just want it to work everywhere."

Can somebody in those shoes fill me in a bit?

Thanks,
Dan

[packaging] LSB Package API
Submitted by robert.schweikert on Tue, 06/24/2008 - 12:00.

Dan Kegel wrote:
>
>
> Can somebody in those shoes fill me in a bit?
>
OK, I'll try.

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.

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.

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.

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.

Hope this helps,
Robert
> Thanks,
> Dan

[packaging] LSB Package API
Submitted by tytso on Mon, 06/30/2008 - 20:00.

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
sandardization.

> 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.

Regards,

- Ted

[packaging] LSB Package API
Submitted by dank on Mon, 06/30/2008 - 20:15.

On Mon, Jun 30, 2008 at 12:47 PM, Theodore Tso wrote:
> 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.

Incidentally, this is also the problem with the Suse Build Service.

> 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.

Indeed. But if, say, Installshield or InstallAnywhere or their ilk
wanted, they could have their tool spit out .msi, .deb, and/or .rpm
as appropriate. That could render the Berlin Api moot.

There seems to be a market opportunity here for some open source
tool to step in and help solve packaging in a way friendly to
package managers on all platforms.
- Dan

[packaging] LSB Package API
Submitted by tytso on Mon, 06/30/2008 - 21:00.

On Mon, Jun 30, 2008 at 01:00:56PM -0700, Dan Kegel wrote:
> There seems to be a market opportunity here for some open source
> tool to step in and help solve packaging in a way friendly to
> package managers on all platforms.

We thought about doing something like this. The basic idea here was
to create a tool which would take a directory hierarchy (i.e., the
sort of thing that would be created via a "make install DESTDIR=/tmp/dest"),
some basic amount of metadata that would be provided via either an XML file
or through a series of command-line options to provide things like the
package name, description, version number, post-install/pre-remove scripts,
etc. and generate an LSB-compliant RPM.

The thinking was that such an RPM could be easily consumed by alien
aka lsb_install on Debian/Ubuntu systems, but it wouldn't be that hard
to generate a .deb file using either alien or directly from the tool.
(It's actually easier to generate .deb files directly because
low-level interfaces such as dpkg-gencontrol and dpkg --build will do
most of the heavy lifting for you; with RPM there are no easy-to-use
programs that can be easily called from a shell/perl/python script.)

My thinking is this is would be in addition to the Berlin API; for
people who are willing to modify their build engines to generate
native Linux package files, this approach is certainly better and
"purer". Unfortunately, some ISV's want to use the same graphical GUI
install on all platforms, which are pixel-for-pixel identical on
Linux, Solaris, AIX, etc., because it simplifies their documentation
(they don't want OS-specific screen shots). For those ISV's they will
always find the Berlin API approach to be preferable.

Regards,

- Ted

[packaging] LSB Package API
Submitted by tytso on Tue, 07/01/2008 - 18:00.

On Tue, Jul 01, 2008 at 08:19:37AM -0400, Matthew Tippett wrote:
> Our end result is that we took the path of releasing a monolithic
> installer, but included the mechanism to build and install packages *on
> the user's machine*. This seems to be the happy medium. Users who
> don't understand packaging can download and install with the ".bin"
> mode, and experts can generate their packages and install those.

It's definitely the case that if you need to generate 3rd party kernel
modules which work on whatever kernel/kernel-headers the user has
installed, locally generated packages on the user's machine makes the
best amount of sense. On my T60p laptop, which used the ATI chipset,
I used the fglrx modules and the packaging you and your team developed
worked very well.

Other ISV's may have other constraints/priorities which may cause them
to produce other solutions; for example Robert articilated his
requirement of non-root installation in the user's home directory.

One of the things that might be interesting is if ISV's are interested
in collaborating on packaging technologies for their respective
requirements/constraints, I could imagine different communities of
interest working that worked on different packaging (or
meta-packaging) technologies on an open source basis. For example, if
AMD/ATI were interested in collaborating with other ISV's that need to
ship products that use externally generated kernel modules (in some
cases said modules might be available all in source form, such as in
he case of Rational Clearcase and VMWare; in others there might be
binary components, such as ATI and Powerpath), that would be great.

Or if the there are some companies that want to collaborate on
mechanisms for non-root, unprivileged package management in the user's
home directory, that's great too. There's plenty of room for
experimentation.

Regards,

- Ted

LSB Package API

Active forum topics