[MacPorts] #17540: poppler conflicts with xpdf

MacPorts noreply at macports.org
Tue Feb 17 16:19:17 PST 2009


#17540: poppler conflicts with xpdf
----------------------------+-----------------------------------------------
 Reporter:  gale@…          |       Owner:  ricci@…           
     Type:  defect          |      Status:  new               
 Priority:  Normal          |   Milestone:  Port Bugs         
Component:  ports           |     Version:  1.6.0             
 Keywords:  conflict        |        Port:  poppler xpdf      
----------------------------+-----------------------------------------------

Comment(by gale@…):

 Replying to [comment:7 jeremyhu@…]:
 > How is it "dangerous",

 Because it tricks people into running a different
 executable than they think they are running.

 > and how is it a "hack" ?

 Wouldn't you agree that a package that silently
 deletes files belonging to a different package and
 clobbers them with its own is a hack?
 Especially if some of those files are executables?

 > A variant is in place in xpdf to "make it work".

 Not for me, I also would need a variant in poppler to be able to use this
 hack.

 > The utilities ARE binary compatible.

 Could be at this moment. But even if so, that could change without warning
 at any time.

 > As a solution to satisfy you, we could add a 'no_poppler' variant which
 would then result in the current default situation and the current
 +poppler would become the new default.

 Yes, assuming that we also add a +with_xpdf variant to poppler, that would
 satisfy my personal needs currently. But it would still be a dangerous
 hack. Unless there is some way to specify a conflict that is conditional
 on variants across two different packages,
 the only way to do this is to separate out the utilities from the X app
 for xpdf, and from the library for poppler.

 But really, why not do that, like the others are doing? It is easy to
 build the utilities separately (at least for xpdf, I assume also for
 poppler).
 And you gain the additional advantage of vastly reduced dependencies.

-- 
Ticket URL: <http://trac.macports.org/ticket/17540#comment:8>
MacPorts <http://www.macports.org/>
Ports system for Mac OS


More information about the macports-tickets mailing list