Opened 11 months ago

Last modified 10 months ago

#68970 new defect

libreoffice @7.6.3.2_1: depends unconditionally on unixODBC, which can lead to build conflicts

Reported by: cooljeanius (Eric Gallager) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.8.1
Keywords: Cc: Tatsh (Andrew Udvare)
Port: libreoffice

Description

libreoffice has port:unixODBC under its depends_build-append section. However, unixODBC has a number of conflicts, which can prevent upgrades:

--->  Computing dependencies for unixODBC
DEBUG: Checking for conflicts against unixODBC
DEBUG: Searching for dependency: virtuoso
DEBUG: Found Dependency: receipt exists for virtuoso
DEBUG: Searching for dependency: virtuoso-7
DEBUG: Found Dependency: receipt exists for virtuoso-7
DEBUG: Searching for dependency: libiodbc
DEBUG: Found Dependency: receipt exists for libiodbc
Error: Can't install unixODBC because conflicting ports are active: virtuoso virtuoso-7 libiodbc
Error: Problem while installing unixODBC
DEBUG: Rebuilding port libreoffice finished with status 1
DEBUG: rev-upgrade failed: Error rebuilding libreoffice
    while executing
"error "Error rebuilding $portname""
    (procedure "revupgrade_scanandrebuild" line 460)
    invoked from within
"revupgrade_scanandrebuild broken_port_counts $opts"
Error: rev-upgrade failed: Error rebuilding libreoffice

I'm wondering if this dependency could be switched to be a path:-style dependency instead?

Change History (4)

comment:1 in reply to:  description Changed 11 months ago by ryandesign (Ryan Carsten Schmidt)

Replying to cooljeanius:

I'm wondering if this dependency could be switched to be a path:-style dependency instead?

My initial thought is that I don't think it can, because I don't think unixODBC and libiodbc are drop-in replacements for one another. Of all the ports that depend on unixODBC today, only one does so using a path:-style dependency, and it's pure-odbc, and I'm not sure why I did it that way when I created that port, but that might have been during a brief period when I was trying to use path: dependencies for everything. But I am remembering, for example, the php*-odbc ports where a different patchfile and different configure args need to be used depending on whether unixODBC or libiodbc is selected by variant.

Normally a port for a program that supports either unixODBC or libiodbc should have variants so that the user can choose which library will be used and if one is to be used by default it would be a good idea if all ports could agree on what that default should be.

libreoffice only has unixODBC as a build dependency, which makes me think it does not use the library. I'm not sure what part of unixODBC it does use. Possibly that port is the same between the two ports and a path: dependency could be used.

It might be nice if unixODBC and libiodbc didn't conflict. Whichever of them is "best" might stay where it is and the other one could move to a subdirectory of /opt/local/libexec. All ports that depend on it would have to change following that move.

comment:2 Changed 11 months ago by cooljeanius (Eric Gallager)

Besides the conflict with libiodbc, there are also the conflicts with virtuoso and virtuoso-7...

comment:3 Changed 10 months ago by ryandesign (Ryan Carsten Schmidt)

For background on these conflicts see #41664/#55661/#55662/#55664/#55665.

I see you left a comment that the virtuoso conflict may not be needed anymore. Indeed the conflict was removed from the virtuoso port so the reciprocal conflict should have been removed from unixODBC at the same time.

As far as I can tell, virtuoso-7 never conflicted with unixODBC, though it (and virtuoso) did for a time declare a build conflict (conflicts_build) with unixODBC, but that's different from and unrelated to the activation conflict keyword (conflicts).

comment:4 in reply to:  3 Changed 10 months ago by cooljeanius (Eric Gallager)

Replying to ryandesign:

Indeed the conflict was removed from the virtuoso port so the reciprocal conflict should have been removed from unixODBC at the same time.

As far as I can tell, virtuoso-7 never conflicted with unixODBC, though it (and virtuoso) did for a time declare a build conflict (conflicts_build) with unixODBC, but that's different from and unrelated to the activation conflict keyword (conflicts).

so it should be ok to remove then, right?

Note: See TracTickets for help on using tickets.