Re: PATCH: dpkg: allow missing /etc/dpkg/dpkg.d directory
Anders Oleson writes ("Re: PATCH: dpkg: allow missing /etc/dpkg/dpkg.d 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".
So your build system reuses builds with baked-in paths, after those
paths have been invalidated ? That's ... not going to go well.
AIUI you have been trying to fix this by overriding all of the
baked-in paths at runtime ?
But the dpkg CONFIGDIR cannot be overridden at runtime, so that fails.
IMO it would be better for your to avoid baking in these kind of
ephemeral paths. You could set CONFIGDIR at compile time to
/dev/this-directory-does-not-exist.
> 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.
If you did that you would still have a problem because `joe' can cause
arbitrary weirdness by putting actual files in this location which
dpkg would read and honour.
> > 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?
If a program has not been able to read its configuration, it should
not blunder on processing based on the half it has been able to read.
> > 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'll let Guillem (the current maintainer) comment on these details,
but I think these would be reasonable directions.
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: