Fwd: Re: ImageMagick modules (Re: ImageMagick - portupgrade failure -amd64 openexr issues)

David Southwell david at vizion2000.net
Tue Oct 16 07:01:27 PDT 2007

----------  Forwarded Message  ----------

Subject: Re: ImageMagick modules (Re: ImageMagick - portupgrade failure -amd64 
openexr issues)
Date: Tuesday 16 October 2007
From: David Southwell <david at vizion2000.net>
To: Mikhail Teterin <mi+kde at aldan.algebra.com>

On Tuesday 16 October 2007 05:44:25 you wrote:
> On вівторок 16 жовтень 2007, David Southwell wrote:
> = On Tuesday 16 October 2007 05:24:15 you wrote:
> = > On вівторок 16 жовтень 2007, David Southwell wrote:
> = > = > How about a patch for the makefile?
> = >
> = > Which makefile? ImageMagick's or portupgrade's? The warning is
> legitimate = > -- older version of OpenExr /may/ interefere. It may not --
> depending on = > too many circumstance to check within ImageMagick's
> makefile.
> =
> = A few things to think about.
> =
> = In response to your question maybe both but certainly I feel the
> = ImageMagick's makefile should check whether the installed version of
> OpenEXR = necessitates the issue of a warning. The Issue of inappropriate
> warnings by = any port is, IMHO, a bug.
> This would complicate the port even further. But do take a crack at it, and
> send me a patch, if you come up with something.
> = > portupgrade ought to proceed despite the warnings -- if there is no way
> to = > force it, that's a bug. But I do not maintain portupgrade
> =
> = I do not agree. The purpose of a warning is to ensure that installation
> = cannot proceed without human interbvention.
> No, that's a purpose of an /error/. A /warning/ is to, uhm, warn...
> Portupgrade seems to be treating warnings as errors, but that is not my
> fault...
> = If every application issued inappropriate warning then would not the
> entire = ports system grind to a halt? A philosophy of warn unless "test
> valid" is = appropriate here.
> It is simply too difficult to /finely/ automatically determine, whether to
> proceed here. So if a simple /crude/ method suggests, there might be a
> problem, I issue a warning and proceed anyway.
> = The focus IMHO needs to be on  what is actually installed. not on what is
> = installed by default. In my case both perl and OpenEXR are installed with
> = threads.
> You are right. But this is too difficult to check for in a port. Try it...
> 	-mi

I agree it can be difficult  in some instances but those can these not be 
limited by careful use of configuration options and dependency management 
where that is not too difficult to implement. For many ports when a user 
selects an option during configuration then the requirements for that option 
can be handled as a dependency (e.g for Imagemagick Perl with_threads=yes (or 
OpenExr Version (xxx.xx) ). So when the option is selected the users choices 
can be implemented so as to enable the upgrade to proceed without throwing 
inappropriate warnings. Users can be advised, during the make config routine, 
of the cponsequences of selecting an option.

My two pennorth


More information about the freebsd-ports mailing list