Bug#712435: apt-cache show output changed/broken when translated descriptions used
On Sun, Jun 16, 2013 at 10:16:30AM +0200, David Kalnischkies wrote:
>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.
Ah, right!
>> 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.
OK, I'll stick with the =none then.
>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.
ACK, sounds reasonable to me. But, as I'm seeing more and more often -
it's amazing how often a minor change like that can have unexpected
consequences.
Thanks for the very quick response to the bug report, it's
appreciated. I know I was very frustrated when I submitted it, and
that may have shown through in my tone. If so, apologies... :-/
It's always the way when we do releases - the first point release is
the one where all the weird off-base bugs happen, as it's the first
one where all the infrastructure is running r0 instead of the previous
stable code that we'd already debugged!
I don't know whether or not to close this bug - it's up to you
really...
Cheers,
--
Steve McIntyre, Cambridge, UK. steve@einval.com
Mature Sporty Personal
More Innovation More Adult
A Man in Dandism
Powered Midship Specialty
Reply to: