On 06/06/2025 8:13 pm, Nicolas Schier wrote:
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
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.
