Hi Joerg,
On Sun, Feb 05, 2012 at 10:25:56PM +0100, Joerg Jaspert wrote:
> > So we have only description_md5 fields filled for sid and experimental.
> > It is lacking for all other releases and I honestly wonder whom to ask
> > to include this in *all* packages files without any exception.
>
> You have them only for suites that have this feature enabled. These are
> all where the following query hits (in projectb):
>
> projectb=> select suite_name from suite where include_long_description is
> false;
> suite_name
> --------------------------
> unstable
> proposed-updates
> testing-proposed-updates
> experimental
> testing
>
> And while proposed-updates is currently in discussion within SRMs, if we
> keep it there, it is entirely unlikely that it will be enabled at all
> for anything "older" than those. Though, if the (O)SRMs request it, we
> would do it, I don't think they will, especially not for oldstable.
>
> Your best bet is to wait until after next release, where it will reach
> stable too.
That's a bit unfortunate because currently UDD is not featuring *any*
long_descriptions at all and I guess the problem report on
debian-devel[1] is connected to this (I have no idea how
packages.debian.org works but it seems probable to me, that this is
connected). So with the current state of input files which are
Packages.gz and Translations* which are in an inconsistent state for
different releases we are certainly breaking applications using data
from UDD.
There are three ways to circumvent this:
1. Provide the missing information in the Packages.gz files
anyway. Joerg, I have no idea how compley to implement
this might be or what chances to break something might
exist.
2. We move English translations from Translation-en.bz2
to the packages table making sure that all existing UDD
applications will work immediately again.
3. We drop long_description field from packages table now
and *calculate* the md5 sums from long_escription for those
releases where it is missing and keep all long_descriptions
inside the ddtp table.
I somehow have the feeling that 2. is the least work and has the
least chances to break something, while 1. and 3. are targeting more
at the future technique (while pushing the work to do on the back
of different people).
Kind regards
Andreas.
[1] http://lists.debian.org/debian-devel/2012/02/msg00149.html
--
http://fam-tille.de
--
To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120206165522.ga26...@an3as.eu
