[Bug 283073] www/rubygem-faraday-gitlab: conflicts with www/rubygem-faraday causing chain reaction of conflicts

From: <bugzilla-noreply_at_freebsd.org>
Date: Mon, 02 Dec 2024 06:44:28 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=283073

            Bug ID: 283073
           Summary: www/rubygem-faraday-gitlab: conflicts with
                    www/rubygem-faraday causing chain reaction of
                    conflicts
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: Individual Port(s)
          Assignee: ports-bugs@FreeBSD.org
          Reporter: jcfyecrayz@liamekaens.com
                CC: mfechner@FreeBSD.org, sunpoet@FreeBSD.org
                CC: mfechner@FreeBSD.org, sunpoet@FreeBSD.org

ports edc8d0390e04 adds two different versions of some rubygem ports to exist
in the ports tree because some ports depend on an older version of some of
those rubygem ports and some ports depend on a newer version.

Just picking one example: www/rubygem-faraday-gitlab was added along side
www/rubygem-faraday.  Right now they are identical - both are built from
faraday-2.12.1.gem, and both install exactly the same files.  And they can't
both be installed because of that (installing the same files to the same
directory locations - e.g., /usr/local/lib/ruby/gems/3.2/gems/faraday-2.12.1/).
 If they were actually different versions the files it appears would not
conflict because they would install to a different directory.

But some ports depend on www/rubygem-faraday-gitlab and some depend on
www/rubygem-faraday.

For instance, net/rubygem-oauth2 depends on www/rubygem-faraday and
net/rubygen-octokit-gitlab depends on www/rubygem-faraday-gitlab.

So those two packages (rubygem-oauth2 and rubygem-octokit-gitlab) cannot be
installed together.  Nor can any ports that require them (e.g.,
sysutils/rubygem-vagrant_cloud and devel/rubygem-licensee) as run-time
dependencies.

Is there a plan to resolve this problem?

I'm wondering if the cure that ports edc8d0390e04 implemented might have fixed
one problem just to make another problem.

Maybe the ports that still want the older version of a rubygem port should look
in a different search location for the older version - for instance, a private
namespace bundled just for the port that needs the older version of the rubygem
port.

-- 
You are receiving this mail because:
You are the assignee for the bug.