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@lists.macosforge.org >>> http://lists.macosforge.org/mailman/listinfo.cgi/macports-users >>> >> 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@lists.macosforge.org > http://lists.macosforge.org/mailman/listinfo.cgi/macports-users > 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. _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
