#16525 closed defect (fixed)
ufraw dcraw file conflict
Reported by: | dershow | Owned by: | ryandesign (Ryan Carsten Schmidt) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.6.0 |
Keywords: | Cc: | frank.mcpherson@…, jp@… | |
Port: | ufraw dcraw |
Description
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.
Change History (7)
comment:1 Changed 16 years ago by dershow
Cc: | dersh@… added |
---|
comment:2 Changed 16 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign@… dersh@… removed |
---|---|
Owner: | changed from macports-tickets@… to ryandesign@… |
Status: | new → assigned |
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?
comment:4 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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.
comment:5 Changed 15 years ago 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?
comment:6 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)
You're right, I didn't think that through. Fixed in r62451 using tricks borrowed from the spawn-fcgi and pango ports.
comment:7 Changed 15 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | jp@… added |
---|
Cc Me!