Package: apt
Version: 1.4.7
Severity: normal
Dear Maintainer,
I've been making use of the RootDir setting for apt-get and have
noticed, since upgrading to Stretch, that it leads to the following
sequence of messages after an apt-get upgrade (I've substituted
"/ROOTDIR/" for my RootDir value setting):
W: Problem unlinking the file /ROOTDIR/ - FileFd::Open (21: Is a directory)
W: Could not open file /ROOTDIR/. - open (21: Is a directory)
W: Could not open file '/ROOTDIR/' - EDSP::Resolve (21: Is a directory)
I think I know the cause.
After looking through the code I tracked it down to the fact that
EDSP::ResolveExternal will, for "internal" solver, call CreateDumpFile
for "solver".
CreateDumpFile is then calling Configuration::FindFile to get
configuration entry Dir::Log::Solver as a filename in this case.
By default Dir::Log::Solver is left unset so that the usual behaviour is
thus for an empty string result to be returned from
Configuration::FindFile and thus there to be no solver dump
created/written to.
However if RootDir is set then Configuration::FindFile, when it gets an
no value or an empty string value for the config name and when there's
no default in the call either, will just return the RootDir value
instead of an empty string result.
So this means in the case CreateDumpFile is getting back the value of
RootDir to use as the solver dump file name when Dir::Log::Solver is
unset (as it is by default). So it tries to open it (as a create new
file) and because it's of course a directory then that leads to the errors.
I would guess this is a bug in the behaviour of Configuration::FindFile
- I've never delved into the workings of apt before, but from a quick
glance at the code in question it doesn't seem sensible to return the
value of RootDir for empty configuration values (as when RootDir isn't
set it just returns an empty string value in such circumstances I think).
Regards,
Matt
