Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#39076 closed defect (fixed)

certsync @1.0.1 and curl-ca-bundle @7.30.0 should be marked as conflicting

Reported by: cooljeanius (Eric Gallager) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 2.1.3
Keywords: Cc: landonf (Landon Fuller), ryandesign (Ryan Carsten Schmidt)
Port: certsync curl-ca-bundle

Description

Trying to install curl-ca-bundle after certsync has been installed results in the following error:

Error: org.macports.activate for port curl-ca-bundle returned: Image error: /opt/local/etc/openssl/cert.pem already exists and does not belong to a registered port.

It's also odd that it says that it doesn't belong to a port, because I'm pretty sure it was created by certsync... Maybe that was in the post-activate step?

Change History (7)

comment:1 Changed 11 years ago by cooljeanius (Eric Gallager)

also:

gl00b05048:~ egall$ port contents installed
Port certsync contains:
  /opt/local/bin/certsync
  /opt/local/bin/update-ca-certificates
  /opt/local/share/curl/curl-ca-bundle.crt
Port curl-ca-bundle does not contain any files or is not active.

and after force-installing to move the conflicting files aside:

gl00b05048:~ egall$ port contents installed
Port certsync contains:
  /opt/local/bin/certsync
  /opt/local/bin/update-ca-certificates
  /opt/local/share/curl/curl-ca-bundle.crt.mp_1368358116
Port curl-ca-bundle contains:
  /opt/local/etc/openssl/cert.pem
  /opt/local/share/curl/curl-ca-bundle.crt

comment:2 Changed 11 years ago by landonf (Landon Fuller)

In the words of Highlander, "there can only be one". If we move forward with certsync, the curl-ca-bundle port will no longer be necessary. For now, certsync is experimental and (intentionally) conflicts with curl-ca-bundle:

port -f deactivate curl-ca-bundle
port install certsync

There are a few options to make the CA handling more amenable to multiple certificate-providing ports; for instance, splitting curl-ca-bundle into individual pem files and populating the CA cert directory. However, certsync makes this moot, since it simply synchronizes the openSSL certificate store from the system keychain, which already has support for adding/removing CA certs and mixing the system roots with user and admin-installed certificates. In that regard, there's not any need to maintain a separate CA database.

comment:3 Changed 11 years ago by larryv (Lawrence Velázquez)

Explicitly marked as conflicting in r106023.

comment:4 Changed 11 years ago by larryv (Lawrence Velázquez)

Opened #39091 about removing cert.pem.

comment:5 Changed 11 years ago by landonf (Landon Fuller)

Resolution: fixed
Status: newclosed

larryv@ has marked them as conflicting, closing.

comment:6 in reply to:  5 Changed 11 years ago by cooljeanius (Eric Gallager)

Replying to landonf@…:

larryv@ has marked them as conflicting, closing.

Generally when two ports conflict, and other ports depend on one of them for something that both of them provide, the ports that depend on them should be updated to use path-style dependencies so either of the conflicting ports can satisfy the dependency. In this case the ports in question are:

gl00b05048:~ egall$ port echo depends:curl-ca-bundle
curl                            
osc                                                   
vantages                        
glib-networking                 
mercurial                       
mercurial-devel                 
subversion                      

(although this might be a separate ticket though?)

comment:7 Changed 11 years ago by ryandesign (Ryan Carsten Schmidt)

certsync is still experimental; it was only created a couple days ago and we're currently discussing in other tickets whether certsync is going to replace curl-ca-bundle; if so, we'll just change the dependencies to that at that time.

Note: See TracTickets for help on using tickets.