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

Re: environment for maintainer scripts



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


Reply to: