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.. ):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.
Regards,
Jeremy
On Tue, May 14, 2013 at 10:47 PM, Barry Warsaw <barry@ubuntu.com> 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 XML
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@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
--
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™
