On Wed, 30 Apr 2008 05:54:23 -0500, David Wood <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>, Aryeh M. Friedman
<[EMAIL PROTECTED]> 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
--
[EMAIL PROTECTED] - [EMAIL PROTECTED]
FreeBSD GNOME Team
http://www.FreeBSD.org/gnome/ - [EMAIL PROTECTED]
_______________________________________________
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
