Bug#681598: update
On 08/11/2012 09:49 PM, Nikolaus Rath wrote:
> Here we go:
I've played with this a little, using the results from the dir listings
(which don't look odd to me).
>From what I can tell, the ultimate cause of the failure is when apt
decides to invalidate all repositories and "apt-cache policy" only
reports the local dpkg database as a valid "repo". At that point, the
code uses different logic to try and figure out the distro information,
which doesn't include the CODENAME.
So there are a number of ways to fix the problem:
- When unattended-upgrades decides to stop working, I would bet that
"apt-cache policy" only returns the "100 /var/lib/dpkg/status" package
file. Figure out why that's happening and make it not happen, and I'm
sure lsb_release would fall into line.
- Assuming there's a good reason for "apt-cache policy" to do this, we
might be able to do better at guessing the release. We read
/etc/debian_version, and understand versions like "wheezy/sid" (its
current contents as of today). We parse off the "/sid" and keep hold of
the prefix (so long as it's not "testing"), but if the apt check fails,
we end up just discarding it. We might be able to fall back to
something like parsing sources.list to determine if we're running sid or
not, and based on that, set the CODENAME.
- Of course, another way to fix this would be for unattended-upgrades
to be a little more robust about a missing CODENAME; maybe it could use
some fallback, or a different value from the info returned by
get_distro_information(), or something.
Anyone want to weigh in on which is the best solution? (or point out
where I'm totally off base)
Reply to: