Re: PATCH: dpkg: allow missing /etc/dpkg/dpkg.d directory
On Sun, Dec 18, 2016 at 7:18 AM, Guillem Jover <guillem@debian.org> wrote:
> Hi!
Greetings!
>>
>> 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.
I started looking at how to do it, and the secondary issue of how to
modify OE/Yocto recipes and classes to make use of it. I came up with
a simple issue that --confdir - looks like the config files are read
before the options are parsed.
> 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).
Since I don't know the architecture, nor even many of the uses of
dpkg, I have to proceed wiht zero knowledge so I concluded that
changing the order of config-file first/options second could easily
change semantics in other peoples other weird environments. In our
weird environment the config files are empty, so it would appear to
work which is dangerous (to others). So I was thinking the way would
be a very simple first pass looking for and parsing just --confdir;
this isn't too bad, could be 10 lines or so.
>
> 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.
>
I'd not do both; either env or command line.
Having noticing DPKG_ROOT/DPKG_ADMIN and even HOME being used, a
DPKG_CONFIGDIR environment variable may be easier and less impact.
Just from the tactical standpoint of getting the necessary data to the
right place without major surgery - the logic can be self-contained in
options.c. But it may be harder on the OE/Yocto side, it would be
asymmetric to the other options and "tunneling" a global or env.
variable underneath an architecture to avoid maintaining it is a
little hacky (in this case I'd take it).
I see where main.c is doing a setenv() of DPKG_ADMIN is that what you
are talking about? I'd think you could either back off that
requirement or maybe only honor the env. if a compile time switch was
present/absent? --enable-env-overrides.
> 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
What if I start with your commit and attempt to make --confdir
functional as a first choice and see how bad it ends up and whether it
solves whatever problem I was trying to solve in the first place? I
can't work this full time, but I'll keep pecking away at it.
Reply to: