Is someone already working on a port that supports Boost 1.35.0?

[Jeremy Messenger]

On Wed, 30 Apr 2008 05:54:23 -0500, David Wood <david at wood2.org.uk> wrote:

> [Additional CCs added by Aryeh noted, but left untouched]
>
> I wanted to retitle this post, but couldn't come up with a summary of  
> what I was trying to say.
>
>
> In message <48181A2A.1000303 at gmail.com>, Aryeh M. Friedman  
> <aryeh.friedman at gmail.com> writes
>> I am top posting because my comments are general and not in  
>> relationship to any given point.   I think Mezz along with Simon both  
>> the right way to handle it for now.   There are several projects that I  
>> am not directly involved designed to tackle this sort of issue with  
>> ports 2.0 being the right long term solution but not needed to solve  
>> this issue per se so I will not discuss it here.   Most of the projects  
>> can be found on Ale's PortsToDo wiki (wiki.freebsd.org/PortsToDo) the  
>> main one not found on there is Jim Staplton's virtual ports DB (which I  
>> think is either in the committ queue or should be since both me an Ale  
>> have signed off on it as being a good idea).  The issue is really not  
>> the infrastruct as you state but the more patchs like this we make the  
>> more likely it is the infrastruct will become problematic down the road.
<snip>
>
> Aryeh - you seem to have something against slave ports. At times, they

I am against slave ports only if those are conflict with master or/and  
other slave ports.

> are very useful. They make the creation and maintenance of client/server  
> ports easy - for example, databases/mysql50-client is a slave port of  
> databases/mysql50-server.
>
> net/freeradius-mysql was created as a slave port of net/freeradius for  
> work being done with pfSense. The need was for a FreeRADIUS package with  
> MySQL support built in. The easiest way to ensure the necessary package  
> is available from the FreeBSD servers is with a slave port. There are  
> times when a slave port that enables one option makes sense.
>
> However, slave ports that enable a single option in their master port  
> can be troublesome. The example that comes to mind here is  
> devel/subversion and the slave ports devel/subversion-perl,  
> devel/subversion-python and devel/subversion-ruby. All these slave ports  
> do is enable the appropriate language binding in Subversion. The options  
> they enable aren't mutually exclusive, but these ports all conflict with  
> each other, which can lead to problems. The language bindings aren't the  
> defaults because of the dependency on a sizeable language port that  
> isn't installed by default (there's also a fourth optional binding,  
> which is Java).

Just input my IMHO for master/slave port.

If freeradius-mysql and subversion-* only install extra files, not change  
how link with other libraries then what freeradius-* and subversion-* are  
doing isn't right solution. These ports need to be more work on correct  
solution to not get in conflict to the each others. Take a look at  
libgda3/libgda3-*, vte/py-vte, libxml2/py-libxml2, avahi-app/avahi-gtk,  
even gstreamer-plugins-* and soon will be boost/boost-python for examples  
to have the right solution.

If those ports also change the link with libraries, then it's difficult to  
have a good solution for it if it has too many options other than enable  
all options to make port bloats. Maybe that rewrite of OPTIONS might help  
as David has said.

IMO, we should try to not create the conflict ports from our own by  
master/slave ports (our fault) unless different kind of ports (*-devel  
also is ok) happen to have same file/directory.

Cheers,
Mezz

> Best wishes,
> David


-- 
mezz7 at cox.net  -  mezz at FreeBSD.org
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/  -  gnome at FreeBSD.org