App installer design: click packages

Jeremy Bell bell.jeremy at
Wed May 15 03:22:41 UTC 2013

Hello. New to the thread and the forum. Already sent a message directly to
cjwatson, I won't repost here. Just wanted to raise the issue of LGPL
compliance, which is not possible for commercial applications in the
proposed system. The dependency system on the debian packaging system is
what allows linux desktop apps to be LGPL compliant, but the new model does
not allow shared library packages or apps that depend on other packages.
Bundling an LGPL library with an app is only possible (and debatably so at
that), if the app is itself LGPL/GPL. This is my understanding based on
personal experience and legal counsel while delivering commercial
enterprise applications. Sometimes, even the LGPL library is dynamically
linked, a commercial license is needed when the library must be bundled
with the installer (for example, to allow offline installs).

In order to allow LGPL compliant applications, your packaging system must
at least do the following (as always, I am not a lawyer, consult a
professional, etc.. ):
1) Applications and their LGPL library dependencies must be packaged and
distributed separately. Bundling is the same as static linking for the
purposes of LGPL compliance, even if the user can theoretically replace the
dynamic library after your app is installed. You may often see this
particular point made explicit by the LGPL author. Having separate package
downloads works. Bundling the .so file in your application package does not
2) Applications must link to the LGPL library dynamically.
3) Users must be able to either modify the existing shared library
binaries, or install a new version in such a way that your application will
use it instead of the original.

I suggested an alternative to the way the desktop system does it, in that
we could allow shared library packages, but have them self contained like
apps, and let the user dynamically "switch" between shared libraries on a
per app basis, including their own custom builds. I have no idea how
technically feasible this would be, however, or whether it would actually
qualify as compliance with the LGPL, but it's the only thing I could come
up with short of allowing apps to download additional shared libraries
after install and load then dynamically, which of course would be a
security risk.


On Tue, May 14, 2013 at 10:47 PM, Barry Warsaw <barry at> wrote:

> On May 14, 2013, at 02:37 PM, Colin Watson wrote:
> >> > Barry spent
> >> >some time looking at 0install, and it wasn't too bad a fit but we would
> >> >still need to solve many of the same system integration problems.
> >>
> >> Is there a list of these issues somewhere?
> >
> >Barry Warsaw would have to speak to that, I think.  But mainly, there's
> >no way for the system to declare any kind of integration facilities at
> >all, as far as I can see, so we'd have to solve that problem anyway.
> What I think Colin is getting at here is that any system is going to have
> to
> deal with declaring the files that allow an app to interoperate with system
> services.  Think along the lines of dbus .service files, .desktop files,
> etc.
> These will be things we might know about right now (such as the above), but
> they maybe be additional integration points in the future.
> Let's say for example, some future system service comes with a new version
> of
> the SDK or OS image, that allows apps to define push notifications, by
> including a .push file that has to get installed somewhere to be
> registered.
> The app itself will only declare that it has a myapp.push, and you won't
> have
> anything like a maintainer script to install myapp.push.  Instead, the
> system's push notifier will have to be responsible for registering a plugin
> with the installer system to say "okay, now when you see .push files, put
> them
> here and do this something to register it."
> You don't want the logic for that in the installer, and you don't want it
> in
> the app.  You want it as part of the system push notifier.  This latter
> will
> register a trigger that gets run whenever the installer sees that an app
> has
> declared a .push file *and* you want it to run over all app .push files
> when
> the system push notifier is installed.  In the latter case, imagine that
> you
> have a dozen apps that support push notifications installed on your phone,
> but
> the system push notifier hasn't been installed yet.  Once it is, all your
> already installed push-enabled apps will Just Work.
> This all means that the installer must have plugins for handling new
> functionality and the declarative manifest must be extensible, i.e. the
> installer will ignore extensions that it doesn't (yet) have a registered
> plugin for.
> I didn't get far enough on 0install (or don't remember ;) whether it has
> that
> capability.
> >I will certainly concede that the rest of 0install is very flexible and
> >has a usefully pluggable design; you seem to have done a good job on it
> >and Barry spoke well of it.  It just seems that there's a bit of a
> >mismatch in that it's kind of over the top in terms of flexibility for
> >what we need and seems to be entirely missing some other things we need,
> >as above; and it would be a lot of code to rewrite in some other
> >language if (as is possible, though not imminent) we decide that Python
> >is just too heavyweight to run routinely on the Ubuntu phone.
> On just few other points:
> I'm not really a big fan of XML formats, since they're not human consumable
> (readable or writable).  Others may disagree, which is fine, but I don't
> have
> any interest in arguing about it.  Probably not a deal breaker, since the
> files can always be generated, either by the 0install tools or something
> that
> takes a JSON or YAML as input, etc.
> I liked that it was fairly easy to wrap executables in "security"
> containers,
> but I didn't dig into this in a lot of detail.
> It seemed to have good security considerations.
> IIRC, there's no built-in support for uninstallation.
> We probably want something like an online-only search REST API for finding
> apps, and then downloading from the URL such a search gives us.  Thus,
> there's
> no cleverness in the repository layout, nor on the device, for finding
> apps.
> Anyway, that's about all the additional stuff I've gleaned from my
> previously
> private experiments with 0install that hasn't already been discussed in
> this
> thread.
> -Barry
> P.S. If we *were* to accept that the installer could be written in Python,
> it
> would *have* to be Python 3.  No more Python 2 on the phone, please!
> --
> ubuntu-devel mailing list
> ubuntu-devel at
> Modify settings or unsubscribe at:

Jeremy Bell
Sleepy Daddy Software™
Have a little one? Try Giggle Pad© for Windows Phone 7, a fun and
educational game for children 9 months and older:

Does your brand new Windows Phone 7 have dead pixels or screen
discoloration? Find out with Pixel Checkup© for Windows Phone 7:

Giggle Pad and Pixel Checkup are copyright © 2010 Jeremy Bell and Sleepy
Daddy Software™
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ubuntu-devel mailing list