Re: PATCH: dpkg: allow missing /etc/dpkg/dpkg.d directory
On Thu, Dec 15, 2016 at 4:53 AM, Ian Jackson
<ijackson@chiark.greenend.org.uk> wrote:
> Anders Oleson writes ("PATCH: dpkg: allow missing /etc/dpkg/dpkg.d directory"):
>> This patch removes the error and message when /etc/dpkg/dpkg.d is missing and
>> instead acts the same as if it were empty.
>
> I think you are confused somehow.
>
> scandir(3) says:
>
> ENOENT The path in dirp does not exist.
> ENOTDIR The path in dirp is not a directory.
Not as confused as you might think. I was however _surprised_ when I had to
track this down. What happened is that CONFIGDIR pointed to a really long
path, something like:
/mnt/home/corp/users/joe/tmp/work/blah/blah/../sysroot/arch/blah/etc.
I can and will reproduce the problem today to reconfirm which errno was
reported and why. I suspect that either the NFS mount disappeared, or that
one of the many directory components was missing or became replaced by a file
(which "joe") is free to do. To make it even more complex, the build
artifacts are "cached" and mirrored and reused, if they are still "valid".
The system is designed to tolerate sysroot location changes without failing,
but dpkg CONFIGDIR being hardcoded violates that. So to the Yocto sstate
cache, dpkg-native with references to "joe's" tmp is still "valid". So in this
context maybe the "Yocto" cross dpkg should either tolerate CONFIGDIR going
away OR turning to a file or a link or a loopback mount to the serial port.
FWIW, if you guys told me this is such a weird use case or that you don't
really support weird distros and environments like this, then I'd not be at
all surprised.
If you do want to, that's fantastic. What's going on is that I'm building an
embedded distro with Yocto and, even though Debian packaging is only
secondarily supported, I really would prefer to use dpkg not rpm.
Also note that this running on a Centos 7.2 host. Don't ask why, not a fan.
>
> If you are getting ENOTDIR from scandir, I think that means that
> /etc/dpkg/dpkg.d is a file, or something. If it is simply missing you
> should get ENOENT which dpkg should tolerate.
>
> I compiled a lightly modified version of the example program from
> scandir(3) and found that indeed,
> scandir("this does not exist", ...)
> fails with ENOENT.
>
>> dlist_n = scandir(dirname, &dlist, valid_config_filename, alphasort);
>> if (dlist_n < 0) {
>> - if (errno == ENOENT) {
>> free(dirname);
>> return;
>> - } else
>> - ohshite(_("error opening configuration directory '%s'"), dirname);
>> }
>
> 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?
Obviously it is your project not mine, so I'm not arguing about what you
should do, simply that it is not universally so and I don't know your
project's philosophy. On my Ubuntu machine at home, dpkg.d is empty. If
scandir returns nothing, the flow of the program works as is and just ignores
it, regardless of why it returned nothing. That being said your position is
not at all a surprise, recall that this is a patch that is applied to the
Yocto dpkg-native cross tool just to get the build done, and I didn't really
intend it as production for full on "Debian". In that sense it was the most
conservative option since it involved very light touch to the code base.
But they expressed a desire to upstream patches (in general), so I
thought I'd see what you thought. If don't-care/don't fail was acceptable,
then why not start the discussion there.
I'm actually quite encouraged that you immediately noticed the niggle about
ENOTDIR because it bugged me too.
>
>> 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.
I'd be willing to reformulate that and test it, but I'd need guidance on the
architecture of the tools to insure that in *ALL* situations the same
CONFIGDIR is used.
>
> Regards,
> Ian.
>
> --
> 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: