<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Hi,</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Mon, Aug 8, 2016 at 12:01 PM, David Garrod <span dir="ltr"><<a href="mailto:dgarrod@extremenetworks.com" target="_blank">dgarrod@extremenetworks.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">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?</span></p></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>- Loïc Minier</div></div></div></div>