On Tue, 04 Dec 2018, Julian Andres Klode wrote:
> Hi folks,
>
> I'm planning to have apt set PATH to a sane value for running
> dpkg, so that maintainer scripts are executed in a sanitized
> environment. That value will be:
>
> PATH=/usr/sbin:/usr/bin:/sbin:/bin
>
> The effect:
>
> (1) There is no /usr/local, which prevents breakage from custom perl
> or python installation
>
> (2) /snap/bin is not included either. This means that packages migrating
> to snaps will have to provide compatibility links (scripts?) in /usr
> - IIRC, lxd already does so, I'm not sure about other libraries.
>
I'm generally in favor of the change, but AFAICS, lxd does *not* do anything
with compatibility symlinks (it uses snap aliases instead, which live in
/snap/bin). lxd may have done this in the past (I vaguely remember something
about that), but snaps shouldn't be doing this and in fact, strict mode snaps
typically cannot (only lxd and a couple of other super-privileged snaps happen
to be able to, but that is considered bad form). As for deb-to-snap migrations,
that still isn't well defined (again, lxd has the ability to do whatever it
wants where most snaps cannot).
That said, debs should always declare their dependencies and atm, debs can't
declare a dependency on a snap. Therefore, including /snap/bin in the PATH is
wrong since its possible that a deb is missing a dependency and sometimes finds
it in /snap/bin. As such, +1 on the change. There might be things to reconsider
depending on how we want to handle deb to snap migrations and especially deb
dependencies on snaps (if that every becomes a thing), but that can wait until
later.
--
Jamie Strandboge | http://www.canonical.com
