Re: Removing long descriptions / english from Packages files
- To: firstname.lastname@example.org
- Cc: 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: Nicolas François <firstname.lastname@example.org>
- Date: Thu, 13 Aug 2009 02:43:45 +0200
- Message-id: <20090813004345.GA29269@nekral.nekral.homelinux.net>
- Mail-followup-to: Nicolas François <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com
- In-reply-to: <firstname.lastname@example.org>
- References: <email@example.com>
(I'm adding dpkg. See the original mail there:
On Thu, Aug 13, 2009 at 12:47:46AM +0200, Joerg Jaspert wrote:
> It will also mean changes to apt-ftparchive, so lets get to the apt
> It would mean changes to apt-ftparchive, so it can (at least in generate
> mode) output the description in a different file. That files layout is
> simple 822 format of lines as
> Package: $PACKAGE
> Description-md5: $MD5
> Description-en: $DESCRIPTION, short and long
> 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.
> (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.
The only drawback would be that when a new version of the package is
available, and the Translation file is not updated, the description would
not be available.
On the other hand, if the goal is to integrate in the archive the
distribution of the Descriptions and their translations, it might be easier
to change the format of the Translation files (for users), and have an
intermediate file format, which can be used by a dak script to create the
final Translation files, based on (Packages, Translation-en).
>From an user point of view, having the version would be more logical. Even
if from a translator point of view, the version is not relevant and only
the content (MD5) counts.
Note: a change of the format need a change in APT (i.e. probably more than
> 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?).
If needed, an "aptitude update" could be recommended in the release notes
after APT has been updated.
There could be more "missing long descriptions" issues for users using
pinning with different releases (even more if the Translation files format
We can check if supporting the two formats is possible.
> - Modify the l10n side (and here its partly guess-work from me what
> needs to happen) to use the new file for the english descriptions as
> input, and adapt the sync process l10n<->ftpmaster. Also who of you
> is/will be behind this?
I think we need to:
* Be prepared to change the input source for the long descriptions.
(The transition should not be a big issues, dak already support delays
Michael, can you handle this?
* Test if the English translation file is downloaded when the user's
locale is set to English
This should be the case, unless there is a specific exception for
I can check this.
* 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.
* 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
dselect might be impacted.
(I do not know if it currently uses the Translation files, I do not know
if it will support empty long descriptions)
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