Bug#681598: update

[Nikolaus Rath <Nikolaus@rath.org>]

On 08/26/2012 10:06 PM, Jeff Licquia wrote:
> 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.

I'll check that and report back.

>  - 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.

The use of CODENAME isn't built into unattended-upgrades, it read
"origin patterns" from its configuration file which may contain
variables like $distro_id or $distro_codename. Therefore, I don't think
a general fallback would be feasible - what's sensible would depend on
the user configuration. That said, it's of course possible to not use
variables at all and just hardcode "testing" or "wheezy".


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C