environment for maintainer scripts

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

environment for maintainer scripts

Brian Murray-5
In Ubuntu we have recently had reports[1] where users were unable to upgrade
python packages because they had installed a version of python in
/usr/local/bin which did not provide the expected functions. While we worked
around this by using the complete path to python in its postinst scripts this
is not an ideal solution because this issue certainly does not just affect
python. Additionally, the python maintainer in Ubuntu is concerned that this
workaround is a violation of the Debian Policy[2] regarding maintainer scripts
- "Programs called from maintainer scripts should not normally have a path
 prepended to them".

This issue of having a clean environment for maintainer scripts was previously
raised[3] in 2002 and on debian-devel mailing list[4], at that time there was
an argument that "the system adminstrator may prefer using a 3rd party version
of adduser". While that is true I think the technical savvy of users of dpkg
has changed since then and peferring a 3rd party version of a utility is now
the less likely case. Subsequently, we could prevent users a lot of pain by
providing a clean environment for maintainer scripts.

Would it be possible to remove /usr/local/bin from $PATH when package
operations are being performed by dpkg?

[1] https://bugs.launchpad.net/ubuntu/+source/python3.5/+bug/1682934
[2] https://www.debian.org/doc/debian-policy/#introduction-to-package-maintainer-scripts
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=18567
[4] http://lists.debian.org/debian-devel/2002/debian-devel-200210/msg00941.html

Thanks,
--
Brian Murray

signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: environment for maintainer scripts

Ian Jackson-2
Brian Murray writes ("environment for maintainer scripts"):

> In Ubuntu we have recently had reports[1] where users were unable to
> upgrade python packages because they had installed a version of
> python in /usr/local/bin which did not provide the expected
> functions. While we worked around this by using the complete path to
> python in its postinst scripts this is not an ideal solution because
> this issue certainly does not just affect python. Additionally, the
> python maintainer in Ubuntu is concerned that this workaround is a
> violation of the Debian Policy[2] regarding maintainer scripts -
> "Programs called from maintainer scripts should not normally have a
> path prepended to them".

That workaround is indeed such a violation (if you consider Debian
Policy to be applicable to Ubuntu).

IMO the correct workaround is to automatically close bug reports of
this form with a polite message indicating that the user is in error.

> This issue of having a clean environment for maintainer scripts was
> previously raised[3] in 2002 and on debian-devel mailing list[4], at
> that time there was an argument that "the system adminstrator may
> prefer using a 3rd party version of adduser".

And I am such an administrator.

> While that is true I
> think the technical savvy of users of dpkg has changed since then
> and peferring a 3rd party version of a utility is now the less
> likely case. Subsequently, we could prevent users a lot of pain by
> providing a clean environment for maintainer scripts.
>
> Would it be possible to remove /usr/local/bin from $PATH when package
> operations are being performed by dpkg?

I think this proposal should be discussed in (or in conjunction with)
debian-policy (CC'd).  Personally I think such a change to set a fixed
the environment could be beneficial but we need to think carefully
about the right layer to do it.

Perhaps it should be done by apt, or a GUI package manager, rather
than dpkg.  And there has to be a way to disable it.

Thanks,
Ian.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

Re: environment for maintainer scripts

Guillem Jover
In reply to this post by Brian Murray-5
Hi!

On Tue, 2017-12-05 at 08:03:28 -0800, Brian Murray wrote:
> In Ubuntu we have recently had reports[1] where users were unable to upgrade
> python packages because they had installed a version of python in
> /usr/local/bin which did not provide the expected functions. While we worked
> around this by using the complete path to python in its postinst scripts this
> is not an ideal solution because this issue certainly does not just affect
> python. Additionally, the python maintainer in Ubuntu is concerned that this
> workaround is a violation of the Debian Policy[2] regarding maintainer scripts
> - "Programs called from maintainer scripts should not normally have a path
>  prepended to them".

Yes, I'd consider this a violation. I've to agree with Ian, that the
correct course of action here is to close such bug reports. This is
entirely a self-inflicted problem.

> This issue of having a clean environment for maintainer scripts was previously
> raised[3] in 2002 and on debian-devel mailing list[4],

Perhaps more relevant is #631081. A recentish new instance of this
discussion happened around
<https://lists.debian.org/debian-devel/2017/10/msg00130.html>.

> at that time there was
> an argument that "the system adminstrator may prefer using a 3rd party version
> of adduser". While that is true I think the technical savvy of users of dpkg
> has changed since then and peferring a 3rd party version of a utility is now
> the less likely case. Subsequently, we could prevent users a lot of pain by
> providing a clean environment for maintainer scripts.

IMO that kind of misses the point. We have defined such policy (no
absolute paths) so that users can override system programs. If a user
has done so, and then we ignore those paths only in maintainer
scripts, this does not avoid breakage from any package contents at
run-time, due to mismatches between the declared versions from
dependencies and the used versions, because in fact the user has
globally overriden the dependency system.

If things break, honestly, the user gets to keep the pieces together,

> Would it be possible to remove /usr/local/bin from $PATH when package
> operations are being performed by dpkg?

I think this would be a bad idea. I'm fine though with something like
adding mechanisms to cleanse or pre-define the environment from within
dpkg, but that should IMO be inert by default.

Thanks,
Guillem

Reply | Threaded
Open this post in threaded view
|

Re: environment for maintainer scripts

Brian Murray-5
On Wed, Dec 06, 2017 at 06:39:36PM +0100, Guillem Jover wrote:

> Hi!
>
> On Tue, 2017-12-05 at 08:03:28 -0800, Brian Murray wrote:
> > In Ubuntu we have recently had reports[1] where users were unable to upgrade
> > python packages because they had installed a version of python in
> > /usr/local/bin which did not provide the expected functions. While we worked
> > around this by using the complete path to python in its postinst scripts this
> > is not an ideal solution because this issue certainly does not just affect
> > python. Additionally, the python maintainer in Ubuntu is concerned that this
> > workaround is a violation of the Debian Policy[2] regarding maintainer scripts
> > - "Programs called from maintainer scripts should not normally have a path
> >  prepended to them".
>
> Yes, I'd consider this a violation. I've to agree with Ian, that the
> correct course of action here is to close such bug reports. This is
> entirely a self-inflicted problem.
>
> > This issue of having a clean environment for maintainer scripts was previously
> > raised[3] in 2002 and on debian-devel mailing list[4],
>
> Perhaps more relevant is #631081. A recentish new instance of this
> discussion happened around
> <https://lists.debian.org/debian-devel/2017/10/msg00130.html>.
>
> > at that time there was
> > an argument that "the system adminstrator may prefer using a 3rd party version
> > of adduser". While that is true I think the technical savvy of users of dpkg
> > has changed since then and peferring a 3rd party version of a utility is now
> > the less likely case. Subsequently, we could prevent users a lot of pain by
> > providing a clean environment for maintainer scripts.
>
> IMO that kind of misses the point. We have defined such policy (no
> absolute paths) so that users can override system programs. If a user
> has done so, and then we ignore those paths only in maintainer
> scripts, this does not avoid breakage from any package contents at
> run-time, due to mismatches between the declared versions from
> dependencies and the used versions, because in fact the user has
> globally overriden the dependency system.
>
> If things break, honestly, the user gets to keep the pieces together,
>
> > Would it be possible to remove /usr/local/bin from $PATH when package
> > operations are being performed by dpkg?
>
> I think this would be a bad idea. I'm fine though with something like
> adding mechanisms to cleanse or pre-define the environment from within
> dpkg, but that should IMO be inert by default.

I believe having those mechanisms would accomplish what we are looking
for in Ubuntu. How could these be added to dpkg?

--
Brian Murray