Please Help - can't install ufraw

David Evans devans at
Tue Oct 19 10:17:29 PDT 2010

 On 10/19/10 10:05 AM, Eric Hall wrote:
> On Tue, Oct 19, 2010 at 09:55:37AM -0700, David Evans wrote:
>>  On 10/19/10 8:48 AM, David Evans wrote:
>>>  On 10/19/10 8:31 AM, Ryan Schmidt wrote:
>>>> On Oct 19, 2010, at 10:24, David Evans wrote:
>>>>> On 10/19/10 8:14 AM, Ryan Schmidt wrote:
>>>>>> Why don't we delete that variant and make the xpdf port always do that?
>>>>> I agree but there is a political history behind this.
>>>>> Xpdf was first and poppler is an off-shoot of the original xpdf code written
>>>>> as a library to allow other projects to use it.
>>>>> The two have diverged some-what and it has only been relatively recently
>>>>> that
>>>>> xpdf  was modified to allow linking to poppler rather than use its own code.
>>>>> Xpdf web site still doesn't mention poppler although it is the variant
>>>>> that is
>>>>> currently being maintained (xpdf hasn't had a change in a year and then only
>>>>> minor).
>>>>> But the solution that you propose would be the one that works.
>>>>> Perhaps just making the +with_poppler variant a default variant would
>>>>> fix the
>>>>> problem and allow xpdf purists to use xpdf without poppler (if they
>>>>> really never
>>>>> want to use poppler).
>>>> If the variant is kept, I would want it renamed to just "+poppler" (we do not name variants with "with_" or "without_" prefixes in MacPorts).
>>>> Also if the variant is kept my addition of the conflicts keywords needs to be fixed to only apply the conflict if it's actually relevant.
>>> Well, saying it that way sounds a bit too contrived to me so I would
>>> vote to just make the poppler dependency
>>> the default behavior without any variant.
>>> _______________________________________________
>>> macports-users mailing list
>>> macports-users at
>> Conflict between xpdf and poppler resolved in r72519, r72520 as
>> suggested by Ryan. Conflicts statements
>> removed.
> [snip]
> 	As I noted in the reopened ticket:
> 	Did anyone do any testing to verify that the poppler
> command line utilities perform in the same way the xpdf command
> line utilities do? If not, (and there are differences) then I agree
> that this is a "dangerous" sort of change - people who know what
> the xpdf package contains (not just the xpdf X11 pdf viewer) won't
> get what they are expecting.
> 	Making an xpdf-tools and poppler-tools set of ports (or similar)
> and making them not conflict seems like the best solution. I'd suggest
> that the poppler-tools alter the binary and man page names to reflect
> their origin (as they came later than the xpdf tools).
> 	If anyone has a bit of time to make the xpdf-tools (or xpdf-utils,
> take your pick) and poppler-tools ports, that would be a great help.
> 		-eric
> _______________________________________________
> macports-users mailing list
> macports-users at
Since you seem to have a better idea of the issues involved here, I
would suggest that you
take a crack at creating these Portfiles yourself and submit them via
trac for review.  MacPorts
is a self-serve lunch counter and we can always use help from
knowledgeable individuals.

The current fix removes the forced conflict between the two ports which
just makes them
both unusable for anyone.  This is an improvement but there is always
room for more.

More information about the macports-users mailing list