Snappy and Ubuntu Desktop

[Alexander Sack]

On Tue, Apr 21, 2015 at 12:06 PM, Robert Ancell
<robert.ancell at canonical.com> wrote:
> We're looking at how to get Ubuntu Desktop into snaps. We're
> struggling to work out how to create a framework for this. There are
> many problems where snappy doesn't seem sufficient to do this so we'll
> try and start with a simple use case of something that needs to be
> packaged - CUPS (the service that allows us to access printers).
>
> Facts:
> 1. CUPS is required by Ubuntu Desktop.
> 2. CUPS is shared with other desktops e.g. GNOME, KDE. Is also used in
> print servers that will not have desktop frameworks installed.
> 3. CUPS has a system service, which requires a socket /var/run/cups/cups.sock.
> 4. Applications that access CUPS do so via a library (libcups).
> 5. CUPS is just one of many shared services, e.g. SAMBA, Avahi, BlueZ,
> NetworkManager, AccountsService, GVFS, iBus, Zeitgeist, etc.
>
> What is the ideal size of framework? Do we put CUPS into its own snap?

As mentioned in my other mail, there is no ideal size of a framework;
don't worry that a framework gets too big if that makes sense from
architecture point of view.

>
> Are applications just supposed to depend on one framework? How does
> that work if Ubuntu desktop is made up of multiple framework snaps?

Apps can depend on multiple frameworks.

>
> If two applications require different versions of a framework, what happens?

They cannot depend on different versions unless those frameworks are
different frameworks that can be coinstalled.

e.g. if you have a framework-v1 and framework-v2 in the store and they
are coinstallable and corunnable without stepping on each others toes
it is fine to do that. If its not then there cannot be two versions
same framework available to the system as of now.

>
> Where do helper libraries for services live? Applications access CUPS
> through libcups - does every snap then require a copy of libcups?

You could ship the libs as part of the framework or just as helper
libs that get pulled into the snaps at built time. I guess you being
expert could play through what is the better option for this case. The
Zen is that we want to avoid causing troubles for apps just because
pieces they don't control change underneath them.

Size shouldn't be the reason to not include them in the app snap at
least and fwiw we had ideas to make snappy smarter in the sense that
we would try to de-duplicate identical files that are shipped by
multiple parts on a snappy system.


>
> --Robert and Didier
>
> --
> snappy-devel mailing list
> snappy-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel