LSB Package API

[Denis Washington]

On Sun, 2008-06-22 at 11:41 -0800, Jeff Spaleta wrote:
> On Sun, Jun 22, 2008 at 10:02 AM, Denis Washington <dwashington at gmx.net> wrote:
> > I don't think this is a corner case at all. For one thing, propietary
> > applications might just don't play a role _because_ there is no really
> > good distribution method for them - the typical chicken-and-egg problem.
> 
> I do not want to make proprietary applications easy to install.  My
> involvement in Fedora is predicated on the idea that everything I do
> as part of my involvement with this project makes it easier for people
> to stop using proprietary applications.  I would strongly suggest that
> you don't stand up proprietary applications as your primary argument
> or use case for the technology.  If you want this considered seriously
> by this community. Stand up a usage case which benefits open source
> software and wok through that usage case.

Bleeding-edge versions of open-source projects. It would likely benefit
project maintainers to provide installers for new versions of their
software so that users can easily install and use them, even if the
stable version of their distro does not provide the newer version.
Especially trying some beta or release candidate (which no stable distro
will ship) would be made a lot easier. This could in turn increase the
number of people testing a pre-release version of their favorite
open-source applications and, thus, expose more bugs that can be fixed
before the final release. And everybody's happy.

Another usage case is the distribution of very young and small
open-source applications. Those often suffer from not being in any major
distro's repositories yet. If they could provide an installer which
installs the application in all major distros and even integrates it
nicely into the packaging system, more people will be likely to give the
new application a try than when there are just packages for certain
distros or even nothing more than a source distribution. So I see strong
benefits here too.

Anyway, I don't think that we should not make lifes difficult for
propietary application vendors just because some don't like them. I
respect your dedication to a pure free software system, but I don't
think we should force this opinion of all users of Linux. Having an easy
way to install propietary applications does not mean that anybody has to
install such software. It should be easy to those who want (or need) to
do so - and that's a goal of the LSB Package API.

> > Second, this way of distribution will help open-source projects as well.
> > It would make it really easy for them to distribute bleeding-edge
> > versions of there apps that integrate well into the packaging system
> > without having to package for each and every package manager.
> 
> If its that bleeding edge, should it tie in to the packaging system,
> potentially causing problems for the distribution dependency
> resolution?

There will not be any dependency problems. An LSB-compliant application
is required to bundle all libraries which are not guaranteed to be
provided by the LSB, so it won't interfere with the base system here.
Additionally, as much as possible is installed to /opt, so that no
conflicts with distro packages arise.

> Or should it be more like autopackage built as a secondary system?
> Aren't you just re-inventing a new implementation for the problem that
> autopackage has been attempting to solve for years now?  In fact I
> think you should go back and look at autopackage and make a compare
> and contrast between the APIs.  I know why I don't like autopackage.
> it would be useful to know if I'm going to dislike your API for the
> same reasons.

I must admit that I haven't looked much at autopackage yet. I will have
to evaluate it thoroughly in the next days to make a good comparison.
But it is important to note that the LSB Package API is _not_ a
secondary package manager; it always uses the distro's packaging system.

Regards,
Denis