Dear Maintainer, Debian provides two parallel executables. One from the parallel package (gnu parallel) and one from the moreutils package. When both packages are installed, /usr/bin/parallel is gnu parallel, and /usr/bin/parallel.moreutils is parallel from the moreutils package If only moreutils has been installed, then /usr/bin/parallel is parallel from the moreutils package, and /usr/bin/parallel.moreutils is not available. This makes scripts depending on parallel / parallel.moreutils more brittle and error-prone between Debian installations then they need to be. If the package moreutils would provide /usr/bin/parallel.moreutils, even if gnu parallel is not installed, then using parallel from the moreutils package can be made easier between Debian machines. As far as I've understood, currently gnu parallel uses dpkg-divert to rename the moreutils binary.
I believe that coordinating with gnu parallel would be best, as one can use already today parallel.moreutils. If a third name is introduced one will possibly end to have to test for all three names (my guess would be that once there is mparallel, gnu parallel has no reason to create parallel.moreutils). I'm not sure what type of coordination is necessary. If parallel is not installed - no issue If moreutils is not installed - no issue If parallel still renames parallel moreutils, and is installed on a system with moreutils providing parallel.moreutils - parallel fails to install (my assumption), thus (hopefully) the parallel package will be updated. If parallel package does not do the renaming anymore, and installed on a system with parallel.moreutils - no issue If parallel without renaming is installed before moreutils, then the moreutils package with parallel.moreutils - I guess there will be an error during the installation If parallel is updated to the version without renaming, and then one tries to install an older version of moreutils - parallel from moreutils is not available anywhere -> one is forced to update the "latest and greatest" version Thus either one updates both packages (which hopefully would land more or less at the same time) or there is an error during installation (untested assumption), or parallel from moreutils of an older version might not be available. By the way, I've opened also 1107385 against (gnu) parallel, which I propose they should also add parallel.gnu, making it even easier to use both programs.
I believe that coordinating with gnu parallel would be best, as one can use already today parallel.moreutils. If a third name is introduced one will possibly end to have to test for all three names (my guess would be that once there is mparallel, gnu parallel has no reason to create parallel.moreutils). I'm not sure what type of coordination is necessary. If parallel is not installed - no issue If moreutils is not installed - no issue If parallel still renames parallel moreutils, and is installed on a system with moreutils providing parallel.moreutils - parallel fails to install (my assumption), thus (hopefully) the parallel package will be updated. If parallel package does not do the renaming anymore, and installed on a system with parallel.moreutils - no issue If parallel without renaming is installed before moreutils, then the moreutils package with parallel.moreutils - I guess there will be an error during the installation If parallel is updated to the version without renaming, and then one tries to install an older version of moreutils - parallel from moreutils is not available anywhere -> one is forced to update the "latest and greatest" version Thus either one updates both packages (which hopefully would land more or less at the same time) or there is an error during installation (untested assumption), or parallel from moreutils of an older version might not be available. By the way, I've opened also 1107385 against (gnu) parallel, which I propose they should also add parallel.gnu, making it even easier to use both programs.
Hi Federico, thanks for the bug report! You're right, the current situation is suboptimsl. From my first tests, we will have to choose a different name than parallel.moreutils, as this would break the unconditionsl divert-calls from the parallel package. Therefore, I am thinking about renaming moreutil's parallel to mparallel instead and keep a symlink at /ust/bin/parallel for a transitional time. But that feels odd to me. I think parallel.moreutils would have been a better choice, but I don't know how to coordinate that with GNU parallel packaging. Kind regards, Nicolas
Hi Federico, thanks for the bug report! You're right, the current situation is suboptimsl. From my first tests, we will have to choose a different name than parallel.moreutils, as this would break the unconditionsl divert-calls from the parallel package. Therefore, I am thinking about renaming moreutil's parallel to mparallel instead and keep a symlink at /ust/bin/parallel for a transitional time. But that feels odd to me. I think parallel.moreutils would have been a better choice, but I don't know how to coordinate that with GNU parallel packaging. Kind regards, Nicolas