FS#41335 - [libva-intel-driver] Dependency "hell"

Attached to Project: Arch Linux
Opened by Emil (xexaxo) - Thursday, 24 July 2014, 21:36 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Thursday, 07 August 2014, 08:38 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Ionut Biru (wonder)
Bartłomiej Piotrowski (Barthalion)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

Just spotted a few rather interesting issues in the dependency chain:
- The package is a backend for the libva library, as such it never calls into nor it depend of its loader.
Yet it currently links against it. Reported upstream, awaiting response.

- The library links (and explicitly calls) libdrm and libdrm-intel functions. Can we add libdrm as a runtime dependency ?
Or perhaps the package manager is against adding it as a dep, as libva already requires libdrm. IMHO it would be great to have it here, partially due to the issue above also it gives a clear idea of the actual relationship between the libraries.

Cheers,
Emil
This task depends upon

Closed by  Bartłomiej Piotrowski (Barthalion)
Thursday, 07 August 2014, 08:38 GMT
Reason for closing:  Not a bug
Comment by Ionut Biru (wonder) - Friday, 25 July 2014, 13:52 GMT
personally, I don't quite understand what's the issue.
libva exists as dependency because libva-intel-driver doesn't work without libva even if it links or not, libva-intel-driver needs libva to function.

As for libdrm dependency, we can add it but is not required since libdrm is already a dependency for libva.
Comment by Emil (xexaxo) - Friday, 25 July 2014, 14:13 GMT
Perhaps I was not clear enough, let me try again.

- The former is a bug upstream, which I'm seeking to resolve and obviously letting you guys know :)
- Whereas for the latter is a question of explicit vs implicit dependencies. I've heard that Arch do not agree on the topic yet I failed to find any technical discussion. Would you have a link (keywords) at hand ? Personally I'm in favour of explicit deps, see the following example as to why.

Example:
Today libva depends on libdrm but tomorrow it may not. As such, the maintainer would need to check all of libva users for unmet deps. And then the user's users and so on.

Obviously using explicit dependency can lead to circular deps which, if they cannot be resolved in the software project can be noted in the PKGBUILD.

Just my 2 cents :)

-Emil

Loading...