Moving from strict to classic confinement
Eloy García (PC Actual)
eloy.garcia.pca at gmail.com
Tue Mar 28 13:26:31 UTC 2017
2017-03-27 15:14 GMT+02:00 Sergio Schvezov <sergio.schvezov at canonical.com>:
> 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.
>
Ok Sergio, you convinced me :) It is true. i have had to deal with a lot of
problems until getting an almost totally functional snap for my
application, and if the user should have to upgrade manually the snap...
I'll stick on strict mode! :D
> - 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).
>
The "problem" with wallpaperdownloader is that I try to be fully compatible
with the main Desktop Environments in Linux (at the moment, the application
works fine with Unity 7, Gnome Shell. Mate, XFCE and KDE (not yet for
vesion 2.6 but I'm implementing it for version 2.7)). In order to tell the
DE to change the wallpaper I have to use some tools and commands which are
available only for this DE and snap packaging is a challenge for me in
order to take into account all this environments if I cannot "rely on" the
host DE itself (I don't know if I'm expressing myself clearly, sorry for
that)
> - 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 ;-)
>
>
I'll keep an eye on, for sure! Thank you very much!!
Best,
Eloy
--
Eloy García Almadén
More information about the Snapcraft
mailing list