On Tue, Apr 21, 2015 at 12:06 PM, Robert Ancell <[email protected]> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snappy-devel -- snappy-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snappy-devel
