Re: PATCH: dpkg: allow missing /etc/dpkg/dpkg.d directory
Hi!
On Thu, 2016-12-15 at 07:41:17 -0800, Anders Oleson wrote:
> On Thu, Dec 15, 2016 at 4:53 AM, Ian Jackson wrote:
> > Certainly this patch is entirely wrong. Before treating an error as
> > "thing does not exist, carry on", programs should indeed check errno.
> > If the manpage scandir(3) is accurate, I don't think ENOTDIR is a
> > reasonable situation for dpkg to tolerate.
>
> OK, another school of thought is if it doesn't care, don't explode. What is
> the purpose of the error message? Alert the sysadmin to a mistake perhaps?
Ian has pretty much covered this, but just to reinstate that I'm also
of the school of thought that the robustness principle makes no sense
IMO in a controlled environment such as the one dpkg lives in, because
we'd get just garbage otherwise (and we do and did for things were
dpkg has not been strict enough!). :)
> >> The dpkg utility does not currently allow a command line or environment
> >> override of CONFIGDIR,
> >
> > This seems like an obvious missing feature. I imagine a good patch to
> > provide such a change would be accepted. If I were you I would
> > propose the name and semantics here before writing the code.
>
> Ding ding ding! Yes. If we want the production quality cross-support, this
> would be the best option.
>
> Two choices: either a --configdir command line option to override CONFIGDIR or
> an environment variable, say DPKG_CONFIGDIR. Since --admindir is already a
> command line option, I'd think that would be the easiest.
Yes, AFAIR this was also requested recently but cannot find it right now
(maybe it was on IRC, and probably it was from apt developers), and dpkg
itself needs this even for its functional test suite. Although this gets
unfortunately a bit complicated. :(
I started implementing this very briefly in:
<https://git.hadrons.org/cgit/debian/dpkg/dpkg.git/commit/?h=pu/confdir>
but very quickly realized there are several problems.
If using a --confdir option, the problem is that the options parser
runs callbacks while doing option parsing, those have side-effects. In
addition the command-line options should always have precedence over
config file options, so we would need to change the logic to reverse
some of those side-effects, or stash them or something similarly ugly.
Or do a two pass over the command-line arguments to find any possible
--confdir, load that and then process the rest of the arguments (which
would require either hardcoding or signaling that this option needs
such processing).
If using an environment variable, the problem is that currently dpkg
considers this type of variable "security sensitive" and ignores them
(at least for DPKG_ADMINDIR and DPKG_ROOT, and I see the former is not
documented in dpkg(1), will fix that), but not on other commands such
as dpkg-query or dpkg-divert. This might have been a bad decision at
the time, and I'd be open to change it, because dpkg(1) itself can be
used as a wrapper to call dpkg-query for example which means that
those environment variables get neutralized in those cases, which is
inconsistent. But AFAIR, I did that due to concerns from people. So
meh. The other issue to ponder is on the precedence on this kind of
situation, should the alternative confdir from the environment have
higher precedence than the options in the command-line or lower, etc.
So, while I find this very desirable, and even needed for dpkg itself,
I got stuck in this tangled mess. Perhaps someone else can propose
something clever and obvious I've just missed from obfuscating on the
wrong details! :)
Thanks,
Guillem
Reply to: