[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#712435: apt-cache show output changed/broken when translated descriptions used



On Sun, Jun 16, 2013 at 12:50 AM, Steve McIntyre <steve@einval.com> wrote:
>  * eventually, after a lot of debugging by a group of people, we
>    worked out that this was caused by the Packages file missing
>    Description: fields for all the package entries. Not everybody
>    could consistently reproduce the problem (and it certainly wasn't
>    there in squeeze); we worked out that the issue was related to the
>    Acquire::Languages setting.

That's a known bug. Various code particles assume that there is always
a Description available for a package, so you might happen to follow
dangling pointers and other dangerous stuff. In your tests with squeeze
you might just be lucky – squeeze already had Acquire::Languages
implemented, just that the archive didn't used/supported it, but squeeze
didn't had split-out long-descriptions so thats probably your problem.


> For now, I'm working around this in debian-cd by explicitly adding "-o
> Acquire::Languages=none" to the code where I call apt, but I'd love to
> know: is this change a deliberate design decision, or a bug? If it's
> deliberate, could you please explain the reasoning? I can't see
> anything in the Changelog that mentions this behaviour change,
> offhand.

It was always the case that "apt-cache show foo" would show the
Description-$LANG and if that wasn't available Description.
The thing that changed now with the split out long-description for
en is that even LANG=C has a 'translated' long-description in the
form of "Description-en" as "Description" is just a short description.

So using =none might be the best you can do if you don't need the
description for anything - otherwise I would just
sed -i '#^Description-en:#Description:#'
and be done.


For the APT parsing side we should probably accept "translations" in the
Packages file as well instead of just from Translation-* files as there
isn't a real reason not to.


Best regards

David Kalnischkies


Reply to: