Packages with "Provides" tags

[tirolerstefan]

Today, I tried to add "python-cryptography" (from ubuntu bionic) to my aptly mirror filter (configured to pull dependencies). When I try to install this package, apt claims two dependencies as not available: python-cffi-backend-api-min python-cffi-backend-api-max

$ apt-cache show python-cryptography
Package: python-cryptography
[...]
Depends: [...], python-cffi-backend-api-min (<= 9729), python-cffi-backend-api-max (>= 9729), [...]
[...]

I didn't find those packages even on official ubuntu repository. After some seeking, I recognized those packages are provided by "python-cffi-backend".

$ apt-cache show python-cffi-backend 
Package: python-cffi-backend
[...]
Provides: python-cffi-backend-api-9729, python-cffi-backend-api-max (= 10239), python-cffi-backend-api-min (= 9729)
[...]

Is it possible to take "Provides" tags into dependency resolution?

[smira]

aptly considers Provides field, but I think it might be not parsing fully these complex Provides with specific version.

[hsitter]

Please provide a step-by-step list of commands to run to reproduce this. I fail to see a problem with git master.

For the record, the policy says this dependency chain is actually wrong

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.

https://www.debian.org/doc/debian-policy/#virtual-packages-provides

We do however read the Provides all the same and consider it as part of the dep tree.

[mp-chet]

aptly considers Provides field, but I think it might be not parsing fully these complex Provides with specific version.

I can confirm that that's exactly the issue. In MatchesDependency() (https://github.com/aptly-dev/aptly/blob/master/deb/package.go#L319), the Provides field is only considered if the dependency is unversioned - otherwise, Provides is simply ignored.

Note that the passage from the Debian Policy Manual quoted above is no longer accurate. Versioned virtual packages are now legal: https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides The corresponding change to the manual was pushed in June 2019: https://salsa.debian.org/dbnpolicy/policy/-/commit/c70ed71b59c70b6d0ada64513f54052d52c42e5f

[aol-nnov]

@lbolla why is it closed? What's the resolution? WONTFIX?

[lbolla]

@aol-nnov I suspect this issue was closed by mistake. Reopening.

[Woellchen]

Please provide a step-by-step list of commands to run to reproduce this. I fail to see a problem with git master.

For the record, the policy says this dependency chain is actually wrong

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.

https://www.debian.org/doc/debian-policy/#virtual-packages-provides

We do however read the Provides all the same and consider it as part of the dep tree.

It seems that Debian has changed their minds. On the linked page it now reads:

A Provides field may contain version numbers, ...

It would be nice if aptly could support this in the future, because this python-cffi-backend package is kinda annoying otherwise.

[neolynx]

the handling of provided packages has been fixed on master, please try latest CI build !