Hi,
I wonder what principle might be used to obtain the unstable_version in dehs
table.
Example:
udd=# SELECT source, unstable_version, unstable_upstream,
unstable_parsed_version, unstable_status FROM dehs d WHERE source =
'r-cran-maptools' ;
source | unstable_version | unstable_upstream |
unstable_parsed_version | unstable_status
-----------------+------------------+-------------------+-------------------------+-----------------
r-cran-maptools | 0.7.26-1 | 0.7-34 | 0.7-26
| outdated
udd=# SELECT r as release, version, archs, component
udd-# FROM versions_archs_component('r-cran-maptools') AS (r text, version
text, archs text, component text)
udd-# JOIN releases ON releases.release = r
udd-# ORDER BY releases.sort ASC, version DESC;
release | version | archs | component
---------+----------+-------+-----------
squeeze | 0.7.26-1 | i386 | non-free
sid | 0.7.26-1 | i386 | non-free
sid | 0.7-34-2 | amd64 | non-free
which means: If there are different versions in unstable (for different
architectures, which might be the case for non-free or also some not
supported archs), what version is regarded as "latest". IMHO the right
version would be MAX(version) and thus the dehs table is wrong (and
probably the imported dehs data set (but I never looked into this
directly).
This fact leads to some false alarms for the Blends tools and I'd like
to fix this if possible. If you agree that MAX(version) is the
information we want to keep, I'd file a bug report. If you rather
support the philosophy that MIN(version) should be stored (rationale
would be that there is at least one arch which needs an update) I think
we need to store two additional fields: max_version and max_outdated
(or something like this).
What do you think?
Kind regards
Andreas.
--
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/20100805120106.ga20...@an3as.eu
