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

Sat Oct 10 12:44:47 UTC 2015

Hi!

On Wed, 2015-10-07 at 11:25:23 +0100, Manuel A. Fernandez Montecelo wrote:
> 2014-10-30 20:19 Guillem Jover:
> >Package: aptitude
> >Version: 0.6.11-1
> >Severity: normal

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

Thanks, with the additional change suggested by David, this looks
good!

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

Oh, that'd be unfortunate. :/

> 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".

I'd expect the following output given the above package when not installed:

,---
[…]
 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.

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

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.

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

Yes, this looks fine.

> 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

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.

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

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.

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

That's one big issue, yes.

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

Policy is just lagging behind as usual. At some point I assume it will
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