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

Re: Description-less packages file

Hi Stuart,

I just applied your patch on the UDD clone at blends.debian.net.

On Sun, Jan 29, 2012 at 04:07:07PM +0000, Stuart Prescott wrote:
> I volunteered the other day to look at incorporating Description-md5 into 
> UDD and the attached patch deals with this change in the packages tables. I 
> think it is ready to apply to UDD right now

Yes it is.

> as a pre-requisite to fixing the 
> ddtp gatherer (I applied it to my local UDD a week or so ago); unless anyone 
> has any comments on it, I guess I'll commit it to svn soon.

Just commited after testing.

> Sure -- there's a i18n/Translation-en file in the same location as the other 
> translations on the mirrors. That file is in the same format, mapping 
> Description-md5 to the English version of the description.

That's correct and the inclusion of the Description-md5 field is quite
fortunate because it looks promising that I can drop the hackish
workaround using mapping via the Version field which some kind soul from
UDD people (Michael Grisu Bramer) provided in a specific dedicated
location at ddtp.debian.net (which is not reliably online
> The Description-md5 that is in the Packages and Translation files and the 
> values that UDD has been calculating from description and long_description 
> for the ddtp table are identical which should make it easier to adapt to the 
> new setup -- much of the work done by the ddtp gatherer is now done by dak 
> instead which in the long run should make the gatherer much simpler.


> Finding the English long-description for a package will now need to be done 
> with a join against the ddtp table. For UDD users that just want the English 
> text, this is a little more work, but for ddtp, I suspect this will actually 
> be a lot easier because everything is in the same table.

I wonder how many applications are actually using the long_description
field.  All these applications might be currently broken and I wonder
whether anybody has noticed this breakage.

> Are you happy to take on fixing the ddtp gatherer and whatever is using this 
> table? (I think you're in a better position to do so than I am)

While your patch is working it is actually not helpfull in all cases:

udd=# SELECT distribution, release, count(*) from packages where description_md5 is not null group by distribution, release;
 distribution |   release    | count  
 debian       | sid          | 277961
 debian       | experimental |  17792
(2 rows)

udd=# SELECT distribution, release, count(*) from packages where description_md5 is null group by distribution, release;
      distribution       |         release          | count  
 debian-backports        | squeeze                  |  10196
 lenny-volatile-proposed | lenny                    |    205
 debian                  | squeeze                  | 189547
 debian                  | wheezy-proposed-updates  |    108
 debian                  | squeeze-proposed-updates |    321
 debian                  | wheezy                   | 247064
 debian                  | lenny-proposed-updates   |   3054
 debian-backports-sloppy | lenny                    |    409
 debian                  | lenny-security           |  13089
 lenny-volatile          | lenny                    |    127
 debian                  | squeeze-security         |   6348
 debian-backports        | lenny                    |  16196
 debian                  | squeeze-updates          |    235
 debian                  | lenny                    | 171861
(14 rows)

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.

So, yes, I will try to fix ddtp gatherer over this weekend but that's
only half of the solution without complete Description-md5 fields in
*all* packages files.  I can try to work around this because it turns
out that the description_md5 field is only needed really in case there
are different descriptions for different architectures / versions which
is not that frequently the case.  So the import of the English
translations could be done to some extend - but the problem is not
fully solvable in the current state.

Kind regards



Reply to: