Re: Removing long descriptions / english from Packages files
- To: Nicolas François <email@example.com>
- Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
- Subject: Re: Removing long descriptions / english from Packages files
- From: Joerg Jaspert <firstname.lastname@example.org>
- Date: Thu, 13 Aug 2009 09:23:23 +0200
- Message-id: <email@example.com>
- Mail-followup-to: Nicolas François <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
- In-reply-to: <20090813004345.GA29269@nekral.nekral.homelinux.net> ("Nicolas François"'s message of "Thu, 13 Aug 2009 02:43:45 +0200")
- References: <email@example.com> <20090813004345.GA29269@nekral.nekral.homelinux.net>
On 11841 March 1977, Nicolas François wrote:
>> which should be easy enough to output. When such an output file is
>> configured, the descriptions should no longer get written to the
>> Packages files.
> I'm not sure that will be sufficient, unless the Description-md5 field is
> added to the Packages file.
> The system needs a way to detect when a description changes.
That should be doable.
>> (Sidenote: Can we PLEASE DROP MD5 when we are going to work on it?)
> Now, if we want to remove the MD5, we need to introduce another way to map
> descriptions to actual packages.
> This could be done with the package's version.
Think like s/md5/sha256/ or so :)
>> Do you see any problem with us simply going this way and throwing away
>> descriptions, without providing backward "compatibility" files for one
>> release? I just did a short test and neither apt-get nor aptitude nor
>> apt-cache did fail on a missing long description (note that we keep the
>> short one!). So the only bad point I see from a users POV is that on
>> dist-upgrade time they will, for a short timeframe, see packages without
>> a description, unless they use a translation anyways.
> Users should not experience the "missing long descriptions" if they use
> the recommended upgrade process from the release notes (but do they use
> the recommended upgrade process?).
We can only work based on what we tell the users. When they do different
its their fault.
> * Test if the English translation file is used as a fallback (e.g. if the
> current locale is C, or if the language of the current locale dos not
> have the translated description)
> I can check this.
> This might require a change in APT to specify the translation files to
> be downloaded (currently, English is always available, and the
> translation file of the locale used during the apt update is
> I can try to do this if the APT team is overloaded.
Such a change would be a nice thing anyway, so you could completly
disable downloading of translations if you dont want any longdesc at all.
> * We may also need to decide what should be the user interface when a
> description translation is not available. If the English string is
> always used, this would probably force to always download the English
> translation. Another solution could be to have a default description:
> "This long description is not available" translated in the user's
I guess the latter would be nice. It depends on how good the translators
of the various languages are.
If we resort to always downloading english then the user did not win
that much from this change.
> I do not know if dpkg is impacted (currently the available and status
> files contain the long descriptions; dpkg -p will output those
> descriptions, but I'm not sure dpkg would notice if a long description is
It didnt look like it to me, but maybe.
Yeah, patching debian/rules sounds like changing shoes while running the
100 meters track.
-- Michael Koch