On Friday, 21 October 2016 23:03:48 CEST you wrote: > Looks like it gets and uses the first or second hit which is 5.22.2-5 > for an old source package still lingering around.
Good catch. I've also been puzzled sometimes by cme results but I've never found the origin of the issue. > Maybe get_available_version() or cache_info_from_madison() / or > extract_madison_info() could look at binary packages for the current arch > instead of the source version, Well, versioned dependencies are most often specified without taking arch into account, so looking at the available version for current arch will be more complicated. > or for binary instead of source? I like that better. It certainly is enough to get perl version in unstable. On the other hand, what should be done with a case like: $ wget -q -O - 'https://api.ftp-master.debian.org/madison?package=libuv1&b=deb' libuv1 | 1.9.0-1~bpo8+1 | jessie-backports | amd64, arm64, armel, armhf, i386, mips, mipsel, powerpc, ppc64el, s390x libuv1 | 1.9.0-1 | unstable | hurd-i386 libuv1 | 1.9.1-1 | testing | amd64, arm64, armel, armhf, i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x libuv1 | 1.9.1-3 | buildd-unstable | amd64, arm64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x libuv1 | 1.9.1-3 | unstable | amd64, arm64, armel, armhf, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x Which version should be considered as the unstable one ? Could we have a similar problem when trying to cleanup old versions (the one older than old-stable) ? A way around that is to consider amd64 as the "reference" arch to get package version. This would simplify the problem and be correct most of the time. Thoughts ? > Maybe something like this is enough (untested!): That's a good start. Thanks for the patch All the best -- https://github.com/dod38fr/ -o- http://search.cpan.org/~ddumont/ http://ddumont.wordpress.com/ -o- irc: dod at irc.debian.org
