[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