[MacPorts] #56135: protobuf-cpp in conflict with protobuf3-cpp
MacPorts
noreply at macports.org
Sun Apr 22 22:36:11 UTC 2018
#56135: protobuf-cpp in conflict with protobuf3-cpp
-----------------------------------------+----------------------
Reporter: btywoniuk | Owner: blair
Type: enhancement | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version: 2.4.2
Resolution: | Keywords:
Port: protobuf-cpp protobuf3-cpp |
-----------------------------------------+----------------------
Comment (by raimue):
Here is a look at what other distributions are going, because they must
have figured this out already. Most seem to provide
[https://repology.org/metapackage/protobuf/versions protobuf] with version
2.6.x or 3.5.x (the C++ library) and also
[https://repology.org/metapackage/protobuf-c/versions protobuf-c] at 1.2.x
or 1.3.x (a wrapper around the C++ code for pure C).
[https://repology.org/metapackage/protobuf-cpp/versions protobuf-cpp] and
[https://repology.org/metapackage/protobuf3-cpp/versions protobuf3-cpp] do
not exist anywhere else but in MacPorts. I assume this is where all our
problems come from, it is not supposed to be packaged like this in
parallel.
Blair, any comments on why you chose to package it this way? Is there any
reason to keep protobuf 2.x around?
I propose to get rid of protobuf 2.x and simplify this:
1. move protobuf3-cpp to protobuf
1. mark protobuf3-cpp and protobuf-cpp as `replaced_by protobuf`
1. move protobuf3-java to protobuf-java
1. move py-protobuf3 to py-protobuf
1. mark py-protobuf3 as `replaced_by py-protobuf`
This would match what everybody else seems to be doing.
--
Ticket URL: <https://trac.macports.org/ticket/56135#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list