[Aptitude-devel] Bug#767393: aptitude: Does not show version for versioned Provides

Wed Oct 7 10:25:23 UTC 2015

Control: tags -1 + moreinfo

Hi,

Thanks for the report and the nice test case.

2014-10-30 20:19 Guillem Jover:
>Package: aptitude
>Version: 0.6.11-1
>Severity: normal
>
>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
>`---

I implemented this, now it shows:

  Provides: coreutils (1000), dpkg (1:0), test-nonexistent (1.0)

(will omit parentheses and version if version empty)

>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
>`---

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"):

  --\ Versions of dpkg (3)
  i    1.18.3
  p    dpkg:i386 1.18.3
  i    test-provider 10

So, as a summary of the behaviour of the TUI, the fact that under
"Package names provided by test-provider" appear not just the name and
versions provided by this package, but also the state of the virtual
packages as present/installed in the system (when real packages are
involved) is useful, I think, and if it wasn't provided in this place we
would have to find another place within the package screen (apart from
"Virtual Packages" undet the main tree in the default grouping) to show
similar information, to see all co-existing versions of virtual packages
related with the current package.

The only real problem that I see in the whole behaviour of the TUI is
that the version of dpkg provided by "test-provider" doesn't appear
anywhere.

So, I went to read policy to learn more about the virtual packages and:

  http://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual

  "If a relationship field has a version number attached, only real
  packages will be considered to see whether the relationship is
  satisfied (or the prohibition violated, for a conflict or breakage).
  In other words, if a version number is specified, this is a request to
  ignore all Provides for that package name and consider only real
  packages. The package manager will assume that a package providing
  that virtual package is not of the "right" version."

Furthermore:

  "A Provides field may not contain version numbers, and the version
  number of the concrete package which provides a particular virtual
  package will not be considered when considering a dependency on or
  conflict with the virtual package name.[52]"

That looks to me as to indicate that "Provides: pkg1" should never have
an version, because if there is a "Depends: pkg1 (<< 1.0)" the virtual
packages would be discarded, only "Package: pkg1" would be considered.

So unless this request that you are mentioning is because of changes in
functionality that will cause updates in policy, versioned provides are
not supported [yet], and aptitude already ignores the versions of the
Provides.  Apart from your testcase, there is only another in my
dpkg/status with a version ('Provides: libjpeg62 (= 1:1.4.1-2)').

So please clarify if this is needed for future changes or what is the
situation now.

Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>