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

Re: Removal of upstart integration



On Thu, Oct 05, 2017 at 06:08:15PM +0100, Colin Watson wrote:
On Tue, Sep 26, 2017 at 09:13:46PM +0200, Christian Seiler wrote:
On 09/26/2017 09:03 PM, Ansgar Burchardt wrote:
> Arguably `dpkg` could also run maintainer scripts in a more controlled
> environment so less random variables affect the maintainer scripts.

Full ACK. IMHO it should be specified which environment
variables are passed to the maintainer scripts from the
outside, and any variable not on the list should be
unset (or given their default values).

I think something like this would be a good idea, but since it has been
otherwise for so long, there will be many devils in the details.

 - TERM, possibly DISPLAY (for debconf and similar prompts)

   Though if I understand debconf correctly the maintainer
   scripts don't actually need the DISPLAY variable, as they
   use a socket to communicate with debconf, or am I wrong
   there?

The frontend is often started via the confmodule sourced by a maintainer
script (and then the maintscript re-execed under the frontend), so for
better or worse you do need DISPLAY and the like in the current design.

What about setting a flag in the package asking dpkg to use a restricted environment, in hopes of eventually having dpkg reject packages that can't install with a restricted environment? That way, packages would need to opt in (or at least get rebuilt and presumably tested under the newer semantics). It's a longer transition, but maybe quicker to get started.

Mike Stone


Reply to: