[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: environment for maintainer scripts



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 to: