oniguruma5 and oniguruma6 conflict

[delphym (DelphyM)]

This is just a FYI report, as Macport asked me to report it. macOS v: 10.14.6 Macport v: 2.6.2 affected ports: oniguruma5 -> oniguruma6, jq @1.6_1

---

After a while I wanted to install a new macport, but have been warned my macport is old so I should run sudo port selfupdate, so I did, but it ended up with following error and suggestion to report a bug:

Error: Can't install oniguruma6 because conflicting ports are active: oniguruma5
Error: Problem while installing oniguruma6
Error: Follow https://guide.macports.org/#project.tickets to report a bug.

I think I've managed to resolve it by following this Stackoverflow post ​Resolving a macports installation 'conflict'.

I simply tried to uninstall, but then reading the post suggesting to rather only deactivate the conflicting active port, followed with installation of the new version which wanted to rebuild the dependant port.

On the command line it looked like this:

ζ sudo port deactivate oniguruma5                                                                                                             
Note: It is not recommended to uninstall/deactivate a port that has dependents as it breaks the dependents.
The following ports will break: jq @1.6_1
Continue? [y/N]: y
Warning: Deactivate forced.  Proceeding despite dependencies.
--->  Deactivating oniguruma5 @5.9.6_p1_0
--->  Cleaning oniguruma5

Then

ζ sudo port install oniguruma6                                                                                                                
--->  Fetching archive for oniguruma6
--->  Attempting to fetch oniguruma6-6.9.5_0.darwin_18.x86_64.tbz2 from https://packages.macports.org/oniguruma6
--->  Attempting to fetch oniguruma6-6.9.5_0.darwin_18.x86_64.tbz2.rmd160 from https://packages.macports.org/oniguruma6
--->  Installing oniguruma6 @6.9.5_0
--->  Activating oniguruma6 @6.9.5_0
--->  Cleaning oniguruma6
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  Found 2 broken files, matching files to ports      
--->  Found 1 broken port, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt: jq @1.6
Continue? [Y/n]: y
--->  Computing dependencies for jq
--->  Fetching archive for jq
--->  Attempting to fetch jq-1.6_2.darwin_18.x86_64.tbz2 from https://packages.macports.org/jq
--->  Attempting to fetch jq-1.6_2.darwin_18.x86_64.tbz2.rmd160 from https://packages.macports.org/jq
--->  Installing jq @1.6_2
--->  Cleaning jq
--->  Computing dependencies for jq
--->  Deactivating jq @1.6_1
--->  Cleaning jq
--->  Activating jq @1.6_2
--->  Cleaning jq
--->  Scanning binaries for linking errors
--->  No broken files found.                             
--->  No broken ports found.

After that I could carry on with the selfupdate process.

As I said above, I don't expect any immediate fix or solution for my particular scenario would be provided. I'm only reporting it as a FYI because developers seem to be interested in such bugreports to see.

Ideally the fix would do the same step I did in the background or interactively, but it would require kind of AI to analyse each step and possible choice.

Perhaps if the failure on upgrade would rather point out to a specific place in the documentation what to do in such situations rather than a link to report a bug, could be more helpful.

[ryandesign (Ryan Carsten Schmidt)]

Replying to delphym:

This is just a FYI report, as Macport asked me to report it.

To clarify: MacPorts is not asking you to report a bug; rather, it's letting you know how you can report the problem if you believe it is a bug. We could improve the wording of that message to make that clearer.

Here's what happened. You had jq installed. It depended on oniguruma5. The maintainer of jq then updated jq so that it used oniguruma6 instead.

Normally this would not be a problem. Unfortunately in this case it is because the oniguruma5 and oniguruma6 ports are not designed properly: they conflict with one another. If it is still necessary for us to have multiple oniguruma ports, then they should be fixed so that they do not conflict.

The fact that this change in jq would cause the problem you experienced was anticipated and documented by the maintainer of jq but there's nothing to do about it other than for someone to fix the oniguruma ports.

Perhaps if the failure on upgrade would rather point out to a specific place in the documentation what to do in such situations rather than a link to report a bug, could be more helpful.

I agree that it would be good if more of our error messages provided links to documentation pages with a more detailed explanation of the problem and the user's options for fixing it. But so far we don't have such documentation written.

MacPorts always prints the bug reporting instructions when any error occurs. I'm not familiar with the part of MacPorts base that does that so I wouldn't know how to modify it to skip that for certain known conditions that are not considered bugs.

[Schamschula (Marius Schamschula)]

Both the oniguruma5 and oniguruma6 Portfiles include a line indicating the conflict. This is as it should be.

[delphym (DelphyM)]

Replying to ryandesign:

Replying to delphym:

This is just a FYI report, as Macport asked me to report it.

To clarify: MacPorts is not asking you to report a bug; rather, it's letting you know how you can report the problem if you believe it is a bug. We could improve the wording of that message to make that clearer.

Thank you for the great explanation.

Yes, technically speaking it doesn't tell me "Go and report the bug", but kind of felt it would be for a community benefit to report it anyway. Hope it didn't complicated much things.

Cheers

[ryandesign (Ryan Carsten Schmidt)]

Replying to Schamschula:

Both the oniguruma5 and oniguruma6 Portfiles include a line indicating the conflict. This is as it should be.

Except that the naming convention fooX and fooY (or for some ports foo-X and foo-Y) where X and Y are (major or branch of maybe even full) versions is meant to indicate that they are simultaneously installable ports that do not conflict.

Has duplicate #60867.

[Schamschula (Marius Schamschula)]

That is a good point. I wish someone had pointed that out two and a half years ago when I added the oniguruma6 port.

oniguruma4 and oniguruma5 had previously co-existed in the same way (oniguruma4 has since been obsoleted).

There are only a small number of dependent ports, so it may be feasible to repackage the two versions to install side by side.

I'll have a look.

[delphym (DelphyM)]

That is awesome guys:) Thanks you all for all the effort and hard work.

[Schamschula (Marius Schamschula)]

It looks like there are only two ports that depend on oniguruma5: Etoile[-devel] and jubatus_core.

I've updated the jubatus_core to the current version, which can use oniguruma6.

Etoile is a different matter, it has not been updated on GitHub for four years, with no new release in eight years.

Matter of fact, it may not install at all, regardless of which version of oniguruma is installed, see ​https://github.com/etoile/Etoile/issues/7

I think it may be time to obsolete Etoile, Etoile-devel and GNUMail which depends on them.

[Schamschula (Marius Schamschula)]

It looks like gnustep-base is rather broken: #20775 It seems to be an issue with the GNUstep 1.0 PortGroup which can be fixed. However, with the missing paths set, then gnustep-base fails to configure because of

fatal error: error in backend: MachO doesn't support COMDATs, '.objcv2_load_function' cannot be lowered.

when configuring against Apple clang 1001.0.46.4, rather than gcc-4.2.

Thus, fixing Etoile and GNUMail is unlikely.

[nickgaya (Nick Gaya)]

Thanks for this, I was also somewhat confused by the error message.

One remark, if oniguruma is being pulled in as a dependency then you don't need to explicitly install oniguruma6. It's sufficient to deactivate oniguruma5 and run port upgrade outdated (or upgrade the specific dependent port, such as jq).

Looking ahead, can we make some change to the oniguruma6 port such that we won't have this problem again if a backward-incompatible version 7 is released?

[ryandesign (Ryan Carsten Schmidt)]

Replying to nickgaya:

Looking ahead, can we make some change to the oniguruma6 port such that we won't have this problem again if a backward-incompatible version 7 is released?

Making them co-installable (not conflict) is the solution.