How do I get a postinst stage properly executed - traceroute will not install correctly
loic.minier at ubuntu.com
Tue Aug 9 12:18:01 UTC 2016
On Mon, Aug 8, 2016 at 12:01 PM, David Garrod <dgarrod at extremenetworks.com>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Snapcraft