On Mon, 27 Mar 2017 09:22:03 +0200, Eloy García (PC Actual) wrote: > Hello everybody. > > I currently have a snap package published on the store. It is called > wallpaperdownloader and it is a Java-based application. So far, it has been > packaged using the strict confinement. The application basically downloads > wallpapers from the Internet and sets the wallpaper when the user requests > it. Because there are a lot of desktop environments, I have ended up using > a lot of Linux commands from the java application in order to achieve these > goals. For some DE there is no problem at all: for example, using gsettings > interface, GNOME Shell and Unity change the background flawlessly. MATE is > working properly too (I had to include mate-desktop-common as stage > package) but XFCE and KDE... no way. In addition, some of the most simple > features (open a file explorer for example) don't work. > > I have been testing the classic confinement and all these features work! In > addition, I don't need to include some dependencies like desktop-gtk3 or > use a shell script wrapper to launch the application. Then, I'm considering > to move my snap package from stric to classic confinement but i don't know > the possible implications: > > 1.- Are the interfaces still needed when using classic confinement?
No, they are not. > 2.- From the user point of view: if wallpaperdownloader is already > installed and I change the confinement, when snapd upgrades it, will it > work flawlessly? I mean, the upgrade process will be automatic or it will > require manual intervention from the user? They will need updating. HOME in strict confinement points to the segregated data stores, in classic it is the traditional home. > 3.- As I see classic confinement, it is a feature to make snap packages > more easily but they only will work on a "classic" Ubuntu system. If Ubuntu > is finally migrated to a Snappy system, I guess classic confinement won't > work and all these packages should be migrated to strict confinement again, > am I right? This is correct, a pure snappy based system is not a classic system so classic confinement does not apply. > Thank you all for your time :) A few more considerations: - I would stick to strict having gotten this far and just work on unblocking yourself with interfaces or other means. - strict confinment means you have a stable base (core), while classic means you will have an unstable one (well, not unstable, just different depending on the system where the snap is installed), which means you will have a different set of bugs to deal with depending on the base classic system where the snap is installed. - you shouldn't rely on libraries on classic systems, not all of them with have gtk3 nor will all of them be ABI compatible with the glibc stuff your snap uses (this might be a different story with java). - There is a missing feature in snapd/snap-confine to restrict the library paths the classic confined snap can see, so you need to make sure this is the case for you. This can be mitigated in snapcraft if you build all runnables from parts (in your case the jre which I bet wouldn't be easy). - I am going to be talking again a bout classic confined snaps in one of the upcoming Ubuntu Testing days, so if interested, keep an eye on that ;-) Cheers Sergio -- Sent using Dekko from my Ubuntu device -- Snapcraft mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
