#39491 closed enhancement (fixed)
moreutils conflicts with parallel
| Reported by: | david@… | Owned by: | kurthindenburg (Kurt Hindenburg) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | |
| Keywords: | Cc: | cooljeanius (Eric Gallager), ci42 | |
| Port: | moreutils parallel |
Description
The "parallel" port installs GNU parallel. "moreutils" also installs a utility called "parallel", but it is incompatible with (and less flexible than) GNU parallel. I want to be able to install GNU parallel at the same time as the other utilities from moreutils (like "ts").
Here's how other OSs solve this conflict:
- Fedora doesn't provide the "parallel" utility at all in the moreutils package (I, personally, would be happy with this choice).
- Ubuntu (and maybe Debian as well?) disables the "parallel" utility from moreutils if you install GNU parallel when moreutils is already installed (I would also be happy with this; does macports allow doing this?).
Another option would be to add a "-parallel" variant to the "moreutils" port, and mark it so that it doesn't conflict with the "parallel" port. Is it possible to mark only a particular variant of a port as conflicting?
Prior tickets: Ticket #30972 asked for this conflict to be resolved, but instead the two ports were explicitly marked as conflicting.
Attachments (1)
Change History (13)
comment:1 Changed 11 years ago by larryv (Lawrence Velázquez)
| Type: | request → enhancement |
|---|
comment:2 Changed 11 years ago by cooljeanius (Eric Gallager)
comment:4 Changed 11 years ago by mf2k (Frank Schima)
| Cc: | ciserlohn@… added |
|---|---|
| Port: | parallel added |
| Version: | 2.1.3 |
comment:5 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)
We could go crazy and make a separate subport for each program that moreutils installs. Then the moreutils-parallel port and the parallel port could be marked as conflicting with each other without impacting the other utilities. megatools could become a metaport depending on each of its subports.
comment:6 Changed 11 years ago by david@…
We could go crazy and make a separate subport for each program that moreutils installs
I think that's overkill. I'm not aware of any name clashes with the other moreutils utilities.
I've attached patch "0001-moreutils-New-parallel-variant.patch", which adds a "parallel" variant to the moreutils port.
"moreutils +parallel" won't install if you already have installed the "parallel" port. However, I couldn't find a way to tell the "parallel" port that it conflicts if you already have installed the "moreutils +parallel" variant. I don't think this is currently supported by macports, and it is beyond the scope of this patch.
I've chosen to *not* make "+parallel" the default, because GNU parallel is more featureful and more like xargs. This follows the example of Fedora, whose moreutils package doesn't contain "parallel" at all.
Changed 11 years ago by david@…
| Attachment: | 0001-moreutils-New-parallel-variant.patch added |
|---|
comment:7 Changed 11 years ago by david@…
I replaced the patch "0001-moreutils-New-parallel-variant.patch" with a new version rebased onto the latest trunk.
The new version of the patch also uses "conflicts-append" instead of "conflicts" inside the variant declaration.
comment:8 Changed 10 years ago by kurthindenburg (Kurt Hindenburg)
| Owner: | changed from macports-tickets@… to khindenburg@… |
|---|
comment:9 Changed 10 years ago by kurthindenburg (Kurt Hindenburg)
IMHO removing parallels from moreutils is best and then we can just use the parallels port.
comment:10 Changed 10 years ago by kurthindenburg (Kurt Hindenburg)
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
r122712 - ciserlohn let me know if you want me to remove the conflicts line in parallel port
comment:11 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
Yes, you should remove the conflicts line from the parallel port.
For reference, Homebrew also takes this same approach of marking them as conflicting as of @9df4660, which was committed in response to the ticket I opened with them about this issue, their #16719.