Hi! With versioned Provides, aptitude is not showing the provided versions. Instead, on the TUI it shows the version of the real packages if any, and on the command-line it shows only the package name. Here's an equivs control file to reproduce the issue: ,--- virtual.control --- Package: test-provider Version: 10 Provides: coreutils (= 1000), dpkg (= 1:0), test-nonexistent (= 1.0) `--- On the command-line: ,--- # equivs-build virtual.control # dpkg -i test-provider_10_all.deb # aptitude show test-provider | grep Provides: Provides: coreutils, dpkg, test-nonexistent `--- On the TUI, inside the test-provider package window: ,--- […] Source Package: test-provider --\ Package names provided by test-provider (3) v test-nonexistent <none> <none> i dpkg 1.17.21 1.17.21 i coreutils 8.23-3 8.23-3 --- Packages which depend on test-provider (0) --\ Versions of test-provider (1) i 10 `--- Thanks, Guillem
Hi, Thanks for the report and the nice test case. 2014-10-30 20:19 Guillem Jover: I implemented this, now it shows: Provides: coreutils (1000), dpkg (1:0), test-nonexistent (1.0) (will omit parentheses and version if version empty) I was looking into this, and it doesn't seem very straightforward to fix without creating a significant amount of code. Basically, elements of the tree can be "packages" or "versions", and provides don't fit well in either; shoehorning them into the existing elements will be problematic as well. So before changing this, I was thinking about how to fix this and I am not really sure what is there to fix, and if the current way in which it is displayed is not good, what it should be instead. In other way, I don't know how to treat these "provided with versions". The "screenshot" above is telling that "test-provider" provides package names test-nonexistent, dpkg and coreutils; the former has versions installed but no versions shown, and the last two of which are also real package names, already installed and with the given version (and the candidate version is the same). If one chooses one of the packages providing www-browsers, the line is also "v | www-browser | <none> | <none>", highlighted as installed, the same as with "test-nonexistent" above. That's because as in the case of test-nonexistent, it is a "purely virtual" package whose package name doesn't coincide with any real package (a record with "Package: test-nonexistent"). There is not a much better way to represent the information, I think: there are in fact multiple versions of "www-browser", so it is rightly highlighted as installed, and it doesn't contain information about the versions because in fact there are (or could be) many installed at the same time, so the information about versions is not very meaningful for these purely virtual packages anyway. If one selects the www-browser entry, the next screen is the package screen for "www-browser", which is basically composed of the subtree of packages depending on www-browser, and versions of www-browser, with the installation state flag, action, package name and version, as usual: ... i w3m 0.5.3-24 p midori 0.5.11-2 p surf 0.6-1 i elinks 0.12~pre6-10 i conkeror 1.0~~pre-1+git150730-1 ... Similarly, if one selects "dpkg" when "test-provider" is installed, it appears under the subtree of versions (10 is the version of "test-provider", not "dpkg version provided by test-provider"):
clone 767393 -1 retitle -1 aptitude: TUI/curses does not show version for versioned Provides (virtual packages) tags 767393 + pending - moreinfo stop Cloning bug to separate the issues, please reply to the new bug report if it's about the TUI part. Cheers.
Hi! Thanks, with the additional change suggested by David, this looks good! Oh, that'd be unfortunate. :/ ,--- […] Source Package: test-provider --\ Package names provided by test-provider (3) v test-nonexistent <none> 1.0 v dpkg <none> 1:0 v coreutils <none> 1000 --- Packages which depend on test-provider (0) --\ Versions of test-provider (1) i 10 `--- And with the abeve package installed, and the following one to upgrade to: ,--- virtual-next.control --- Package: test-provider Version: 20 Provides: dpkg (= 2:0), dpkg (= 1.18.0), test-nonexistent (= 1.0) `--- I'd expect this output: ,--- […] Source Package: test-provider --\ Package names provided by test-provider (3) v test-nonexistent 1.0 1.0 v dpkg <none> 1.18.0 v dpkg 1:0 2:0 v coreutils 1000 <none> --- Packages which depend on test-provider (0) --\ Versions of test-provider (1) i 20 `--- Notice the ‘v’ and the versions. I think the only versions relevant here are the ones from the virtual packages themselves, not from any real package instance that name might match with, as shown above. Yes, this looks fine. And this looks also fine, because these are instances (versions) of that virtual package, so printing the real package providing them with their real version and current state is the correct thing to do. I think showing if the package is installed or not, encoded through the color is fine and expected, but showing a version different from the virtual one is not correct, and unexpected. That's one big issue, yes. be updated to document current practice. This has been implemented in dpkg and apt, and I don't see any forthcoming change to the current behavior. This should be documented in the deb-control(5) manpage. The commit message and some code comments in <http://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=5bb02fe80e9f40dcad9703a72f67cf615ff217b5> might give an clearer overview of the implemented changes. Just for reference, these are the commits documenting this: <http://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=453d6bfd6c39deb59b41c34d602f49065ba6f2cd> <http://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=93600b77bec6cb583b65fb817a2b13212c2d0b44> If there's anything unclear I'm happy to try to improve the docs to fix that. Thanks, Guillem