[MacPorts] #16525: ufraw dcraw file conflict
#16525: ufraw dcraw file conflict --------------------------------+------------------------------------------- Reporter: dersh@alum.mit.edu | Owner: macports-tickets@lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Keywords: | Port: ufraw dcraw --------------------------------+------------------------------------------- There is a naming conflict between ufraw and dcraw. The problem is that ufraw installs a file called /opt/local/bin/dcraw while, if I try to install dcraw, it attempts to install the same file, and fails. I am not sure if these are the same version of dcraw or not. But perhaps the best solution, since both ports exist, is to have ufraw depend on dcraw, instead of including its own version of the same code (unless one is a different version, or is patched or something?) The above naming can cause a problem if other ports, such as qtpfsgui, come to depend on dcraw. -- Ticket URL: <http://trac.macports.org/ticket/16525> MacPorts <http://www.macports.org/> Ports system for Mac OS
#16525: ufraw dcraw file conflict ---------------------------------+------------------------------------------ Reporter: dersh@alum.mit.edu | Owner: ryandesign@macports.org Type: defect | Status: assigned Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Resolution: | Keywords: Port: ufraw dcraw | ---------------------------------+------------------------------------------ Changes (by ryandesign@macports.org): * cc: ryandesign@macports.org, dersh@alum.mit.edu (removed) * owner: macports-tickets@lists.macosforge.org => ryandesign@macports.org * status: new => assigned Comment: dcraw already prints a message upon installation explaining that it conflicts with ufraw. I do not know if the dcraw provided by the ufraw port is the same dcraw that is provided by the dcraw port. Would you like to investigate that? -- Ticket URL: <http://trac.macports.org/ticket/16525#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS
#16525: ufraw dcraw file conflict ---------------------------------+------------------------------------------ Reporter: dersh@… | Owner: ryandesign@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 1.6.0 Resolution: fixed | Keywords: Port: ufraw dcraw | ---------------------------------+------------------------------------------ Changes (by ryandesign@…): * status: assigned => closed * resolution: => fixed Comment: I've now investigated. ufraw provides a modified version of the same software provided by the dcraw port. And the README (in ufraw 0.16) says: Do not package the executables generated by by --enable-extras. These extras are there for testing the code during development. They are of no interest to end user. Specifically, if you want to package dcraw, you should use Dave's original code and not UFRaw's modified code. So in r62098, while updating ufraw to 0.16, I removed the --enable-extras configure arg so that ufraw and dcraw will no longer conflict. I added a dependency on dcraw because the description of the ufraw port says it uses the dcraw program. In r62099 I removed the post-activate message from dcraw about the ufraw conflict. -- Ticket URL: <http://trac.macports.org/ticket/16525#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS
#16525: ufraw dcraw file conflict ---------------------------------+------------------------------------------ Reporter: dersh@… | Owner: ryandesign@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 1.6.0 Resolution: fixed | Keywords: Port: ufraw dcraw | ---------------------------------+------------------------------------------ Comment(by jp@…): Whe I did a "port -u upgrade outdated", dcraw failed to install because of /opt/local/bin/dcraw. I assume that its kind of a "race condition" problem: If the dcraw port is upgraded first, the "dcraw" binary would have been removed. But (at least in my setup) it seems that macports tries to build the new dependency dcraw first, which fails. I solved this by forcing a rebuild of ufraw first, but isnt there a way to make this upgrade more smooth? -- Ticket URL: <http://trac.macports.org/ticket/16525#comment:5> MacPorts <http://www.macports.org/> Ports system for Mac OS
#16525: ufraw dcraw file conflict ---------------------------------+------------------------------------------ Reporter: dersh@… | Owner: ryandesign@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 1.6.0 Resolution: fixed | Keywords: Port: ufraw dcraw | ---------------------------------+------------------------------------------ Comment(by ryandesign@…): You're right, I didn't think that through. Fixed in r62451 using tricks borrowed from the spawn-fcgi and pango ports. -- Ticket URL: <http://trac.macports.org/ticket/16525#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS
#16525: ufraw dcraw file conflict ---------------------------------+------------------------------------------ Reporter: dersh@… | Owner: ryandesign@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 1.6.0 Resolution: fixed | Keywords: Port: ufraw dcraw | ---------------------------------+------------------------------------------ Changes (by ryandesign@…): * cc: jp@… (added) -- Ticket URL: <http://trac.macports.org/ticket/16525#comment:7> MacPorts <http://www.macports.org/> Ports system for Mac OS
participants (1)
-
MacPorts