Fixing port www/zope-cmfphoto

Gavin Atkinson gavin.atkinson at ury.york.ac.uk
Sun Sep 18 11:40:35 PDT 2005


On Sun, 18 Sep 2005, Mark Linimon wrote:

> On Sun, Sep 18, 2005 at 11:04:27AM +0100, Gavin Atkinson wrote:
>> my first attempt at understanding the ports build infrastructure.
>
> Well, you've chosen a complex topic on which to dive into it :-)

Often the best way to learn :)

>> Despite zope-cmfphoto declaring it requires Python 2.3 (indirectly, via
>> the USE_ZOPE=yes option), somehow RUN_DEPENDS is being populated with
>> py24-imaging-1.1.5.tbz rather than py23-imaging-1.1.5.tbz - presumably
>> this is being done by the pointyhat build scripts based soley on the fact
>> that it is the newest/default version?
>
> As best I can tell the pointyhat scripts use packages as prerequisites
> for every port that gets built.  (Otherwise, the amount of time required
> for the builds would be vastly increased).  My guess is that the default
> package of py-imaging maps to py24-imaging rather than py23-imaging.
> Let's see if that's correct ....
>
> Here is a graphical map of the dependencies as seen by a system that has
> Python 2.4 installed on it:
>
> http://portsmon.FreeBSD.org/portdependencytree.py?category=www&portname=zope-cmfphoto
>
> So www/zope-cmfphoto depends on lang/python23 and graphics/py-imaging;
> but graphics/py-imaging depends on lang/python (2.4), which would, when
> compiled in a clean system, indeed produce package py24-imaging, not
> py23-imaging.
>
> So this may be more a problem with the framework, not with pointyhat
> (e.g. the fact that you can only depend on a port, not a specific package
> of it).

I wonder if the way forward is to define a list of flags which are to be 
inherited by dependencies...  For example, a similar issue will presumably 
also affect Perl ports, and possibly ports with USE_GCC version 
dependencies (eg if one port is compiled with one version and a dependency 
is compiled with another version of GCC, there is no guarantee the two can 
be linked together).

> My guess would be that we need to mark these as NO_PACKAGE as a workaround
> until Zope can fix their code to not rely on 2.3, as some of these other
> ports have done.

This has since been done.  Once I understand the infrastructure a bit 
more, I might have a look to see if there is a solution to this issue, 
although I suspect it'll be beyond my abilities.

Thanks,

Gavin


More information about the freebsd-python mailing list