FS#65235 - [alsa-utils] fftw-3.3.8-2 conflicts with dropbear-scp

Attached to Project: Arch Linux
Opened by Jeff Pohlmeyer (yetanothergeek) - Wednesday, 22 January 2020, 00:20 GMT
Last edited by David Runge (dvzrv) - Wednesday, 22 April 2020, 12:58 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Anatol Pomozov (anatolik)
David Runge (dvzrv)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
I am unable to update my system since 2020/01/19 because of a conflict between two seemingly unrelated packages: alsa-utils and dropbear-scp.

This is because alsa-utils requires fftw which requires openmpi which requires openssh which conflicts with dropbear-scp.

The only reason alsa-utils requires fftw is because of the "alsabat" utility, so the best solution IMO is to split alsabat into a separate package; that would allow the remainder of alsa-utils to be packaged without the fftw=>openmpi=>openssh dependency chain. The alsabat seems like a rather obscure utility anyway, compared to the more commonly used aplay, amixer, etc.

I have attached a patch that should accomplish this.


Additional info:

Package versions:
* alsa-utils 1.2.1-1
* fftw 3.3.8-2
* openmpi 4.0.2-3
* openssh 8.1p1-2
* dropbear-scp 2019.78-1

(The fftw dependency on openmpi is new, it was not there in fftw-3.3.8-1)


Steps to reproduce:
On a system without openssh, install dropbear-scp, and then attempt to install alsa-utils.

This task depends upon

Closed by  David Runge (dvzrv)
Wednesday, 22 April 2020, 12:58 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed with alasa-utils >= 1.2.2-1
Comment by Doug Newgard (Scimmia) - Wednesday, 22 January 2020, 04:31 GMT
There's a whole lot of things that you can't install if you want dropbear-scp. Honestly, don't know why the executable wasn't just renamed to not conflict.
Comment by Jeff Pohlmeyer (yetanothergeek) - Wednesday, 22 January 2020, 05:28 GMT
scp is called by the remote machine when transferring files. Since the remote machine doesn't always know in advance the name of the subsystem, it simplifies the configuration if it is always named scp.

But whatever you name it, it still doesn't make much sense to me that a simple set of audio utilities should require any sort of SSH installation.
Comment by Jeff Pohlmeyer (yetanothergeek) - Wednesday, 19 February 2020, 10:01 GMT
  • Field changed: Percent Complete (100% → 0%)
I can't see where this problem has been fixed.

Did you confirm that dropbear-scp and alsa-utils can now be installed together?

Could you please be more specific on your comment "Dep is back to optional" ?

Comment by Doug Newgard (Scimmia) - Wednesday, 19 February 2020, 13:39 GMT
I based that on another discussion without actually checking. Looks like it was simply hidden behind a libdep instead.
Comment by David Runge (dvzrv) - Thursday, 20 February 2020, 10:19 GMT
@yetanothergeek: Thanks for the bug report. These types of chained blockers are not easy to detect.

Splitting out alsabat is overkill, but making fftw an optdepends (for alsabat as part of alsa-utils) is surely an option.

As a sidenote: Fftw was extended by openmpi functionality to allow it to operate in a clustered way. Here it might also be an option to only optionally depend on openmpi.

I'll look into the options and get back to you!
Comment by David Runge (dvzrv) - Thursday, 20 February 2020, 23:21 GMT
I've moved fftw to optdepends for alsabat for now.

Please note, that this is nothing more but a temporary fix for your problem, because anything in the tree requiring fftw will lead to the same results (`pactree -rs -d1 fftw`).

As Arch does not (yet) support alternatives, this is unfortunate but currently not solvable in a nicer way. However, I'll also look into making openmpi optional for fftw.

Loading...