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

Re: Removal of upstart integration

Michael Stone writes ("Re: Removal of upstart integration"):
> On Thu, Oct 05, 2017 at 06:08:15PM +0100, Colin Watson wrote:
> >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.

In general I agree that it would be nice if arrangements were made so
that in the usual case, a naive user will not find their shell
environment variables leaking into maintainer scripts.

However, I think that such arrangements are already made.  The
majority of people use "sudo", which AIUI already launders the

Doing the same thing in dpkg seems like a waste of time, and will
needlessly inconvenience people who want to do something unusual.
Many useful effects can be achieved by setting environment variable
which have deep effects: stunt versions of utilities on PATH;
LD_PRELOADs for debugging or tracing; etc.

If it is done in dpkg, there must have a way to tell dpkg to instead
pass (at least) specific variables (and perhaps values).

I think it is of course fine for a package maintainer to say "if you
set weird environment variables which make my programs behave oddly,
that isn't a bug".  The question then is whether what the user has
done is "too weird", which is a question of judgement.  LC_MESSAGES
and most LC_CTYPE=C.utf-8 clearly are not.  PATH=/dev/null clearly is
too weird.  If particular cases come up a lot they should be
documented in policy.

The thing which started this thread was putting options after
arguments.  FTR I think this is OK in maintainer scipts because
someone who runs maintainer scripts with POSIXLY_CORRECT is inviting

But writing that way is a bad habit to get into, because the pattern
will then leak into normal shell scripts which must run in more varied


Ian Jackson <ijackson@chiark.greenend.org.uk>   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 to: