Re:
Ø However perhaps the design issue you're seeing is not with snaps but rather with debs: alternatives should be declarative rather than imperative – each .deb would document the alternatives it'd like to see updated on install/remove/upgrade. If we had that piece of data, we could process it when unpacking a .deb without running the postinst as root. But because right now this information is buried inside a shell script which could be of any form and expects to be run as root, we can't use it without resorting to solutions involving chroots. While I agree that maybe “debs” should have additional declarative functionality like this, that currently isn’t the case. In my view SNAPs should be designed to live in the world that IS not in the world we’d like it to be. To be honest I’m surprised that SNAPs don’t make more use of “chroot” like you elude to. I suspect that running the postinst step inside a “chroot” would allow a lot of things to be done in a secure manner. Not to take this thread off in a different direction but the major issue we’re having in moving a whole subsystem into a SNAP (one that we didn’t write but that we are SNAPifying – it happens to be OpenSwitch) is tracking down and finding all the references the absolute root file system names and then adding the appropriate $SNAP_xxx prefix in front of each of them by CHANGING (yuck) the code. I wish that SNAPs could have made use of chroot and maybe found a neat way to layer the chroot inside the SNAP and the Unbuntu core on top of particular real root directories for R/O access (if the file wasn’t present in the chroot directory). I’m showing my age here but I wish there was a way you could use chroot and the concept that is used in that ancient (but I understand still being sold) OpenVMS O/S that allowed you to define “concealed logical names” mapped to an equivalence LIST that essentially enabled one name to reference a list of real directories in way where the user is totally unaware that the “logical” directory is really an amalgamation of contributions from multiple different places. Anyway I digress, I guess for now I’ll hack a custom solution for the “deb” I’m having issues with due to the postinst not being able to be run. From: [email protected] [mailto:[email protected]] On Behalf Of Loïc Minier Sent: Tuesday, August 09, 2016 8:18 AM To: David Garrod Cc: Didier Roche; [email protected] Subject: Re: How do I get a postinst stage properly executed - traceroute will not install correctly Hi, On Mon, Aug 8, 2016 at 12:01 PM, David Garrod <[email protected]<mailto:[email protected]>> wrote: While I’m sure I could hack this particular case and add a link in the startup of my snap I don’t see this as a general solution. What if a later version of the package changes the name of the file or something. Any true solution has to be based in what is in the postinst for the version of the package being installed. This seems like a general issue to me. In order to make the whole snap concept viable surely you have to be able to take packages unchanged and have your SNAP depend on them just as packages in the non-SNAP world depend on each other. I’d really like to see a mechanism whereby the installation of a SNAP can run the post install configure step in the context of the installation. Maybe that would involve deferring some of this to the snap start if absolutely necessary but in general this would not be needed. Are there any active plans to address this fundamental design issue? It's indeed by design; snaps and debs are different. In the .deb world, you can hack the whole system in the postinst, leading to intrusive changes or problems upgrading, interferences between postinst initiated changes etc. However perhaps the design issue you're seeing is not with snaps but rather with debs: alternatives should be declarative rather than imperative – each .deb would document the alternatives it'd like to see updated on install/remove/upgrade. If we had that piece of data, we could process it when unpacking a .deb without running the postinst as root. But because right now this information is buried inside a shell script which could be of any form and expects to be run as root, we can't use it without resorting to solutions involving chroots. - Loïc Minier ________________________________ DISCLAIMER: This e-mail and any attachments to it may contain confidential and proprietary material and is solely for the use of the intended recipient. Any review, use, disclosure, distribution or copying of this transmittal is prohibited except by or on behalf of the intended recipient. If you have received this transmittal in error, please notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed.
-- Snapcraft mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
