[packaging] LSB Package API

[Bryce Harrington]

On Sun, Jun 22, 2008 at 01:34:31PM -0700, Dan Kegel wrote:
> On Sun, Jun 22, 2008 at 11: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'm not saying this is the only reason, but an important one.) We're
> > just not giving them an easy method of cross-distro integration. I think
> > providing this is important.
> 
> Sure, and that's why I support the LSB.
> Has everybody else given up on it?

I've probably missed part of this discussion, but wanted to inject one
anecdote.

Stand-alone binary package installers are nothing particular novel or
new; I'd gained experience using one, Autopackage, with Inkscape several
years ago.

Inkscape was virtually unknown at the time, so Autopackage gave us a
significant benefit of providing users a way to quickly get Inkscape on
distros that didn't yet include Inkscape.

Before Autopackage we would maintain our own .deb and .rpm rules and
specs, and we hoped Autopackage would obsolete that in favor of having a
"Universal Installer".  Yet that really never came to be.


First, Inkscape became recognized by distros, and they took over
handling our packaging work for us.  Meanwhile, the Autopackage
developers (who had been subsidizing us by maintaining the .autopackage
file for us), turned maintenance over to us.  So on the one hand we were
seeing our team workload *reduce* by relying on
packaging-system-specific stuff, and *increase* by using autopackage.

You might argue that it's different for proprietary software since
distros wouldn't adopt them.  Yet look at Xara, Flash, Opera,
proprietary Java, and so on to see that they can and do (to the level
they're able anyway).


Second, while in theory Autopackage promised "100% easy install,
anywhere", it was not without problems.  The issue always seemed to be
with low level dependencies that varied just subtly enough to break on
one distro or another.  So you ended up doing per-distro testing anyway
(and couldn't count on help from the distro once you figured out the
bug).

I think this is an important point to not dismiss by saying, "The design
wasn't as good as ours is", or "it just needed more testing", or
whatever.  The sad truth is that getting this to work 100% requires
invalidating Murphy's Law.  It's a broad fronted fight against entropy.

I felt like we had tried to change our support from N distros to 1, yet
ended up with N+1.


Third, as Inkscape grew we had to account for more dependencies.
Typically, there'd already be .rpm and .deb packages for them, but we'd
be stuck having to do the autopackage packaging work ourselves.

Now, you might think such an issue is irrelevant for proprietary
software since they'd be packaged with all dependencies already
included.  Yet consider dependencies beyond just dynamic libraries.
Consider if the app wants to interface with external programs or tools
(imagemagick, java, sqlite, ...) or to shared data repositories
(openclipart, fonts, etc.)

Eventually, you find yourself having to do a lot of work that distros
already take care of.


Anyway, to sum up, as much as I loved the idea of autopackage and helped
to advocate it, I really don't think the idea of a "universal installer"
is viable.  In the end it's a lot less effort to just collaborate with
each of the distros and have packaging optimized for each.  And I think
efforts put into creating yet more universal installer techs maybe
better invested in helping bring the existing packaging systems better
into consistency with one another, or establishing "best practices"
documents.

Bryce