Date: Wed, 30 Apr 2008 23:34:13 -0500 From: "Jeremy Messenger" <mezz7@cox.net> To: "David Wood" <david@wood2.org.uk> Cc: "Aryeh M. Friedman" <aryeh.friedman@gmail.com>, Alexander Ryba <ryba@sylow.cs.qc.cuny.edu>, ports@freebsd.org, Jacobus Geluk <jacobus.geluk@gmail.com>, Simon Barner <barner@freebsd.org>, Jim Stapleton <stapleton.41@gmail.com> Subject: Re: Is someone already working on a port that supports Boost 1.35.0? Message-ID: <op.uagkbbdq9aq2h7@mezz.mezzweb.com> In-Reply-To: <Y%2B22DKXf$EGIFA7$@wood2.org.uk> References: <b1ff6f240804250756u483501acyc5a5527bb4b489eb@mail.gmail.com> <20080429184420.GB5010@dose.local.invalid> <48178247.2010008@gmail.com> <20080429212721.GA5795@dose.local.invalid> <4817D91E.1040900@gmail.com> <KsaSHhOu3AGIFA51@wood2.org.uk> <48181A2A.1000303@gmail.com> <Y%2B22DKXf$EGIFA7$@wood2.org.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 30 Apr 2008 05:54:23 -0500, David Wood <david@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@gmail.com>, Aryeh M. Friedman > <aryeh.friedman@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@cox.net - mezz@FreeBSD.org FreeBSD GNOME Team http://www.FreeBSD.org/gnome/ - gnome@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?op.uagkbbdq9aq2h7>