alternative options for ports

[Erik Trulsson]

On Fri, Oct 15, 2004 at 04:04:19PM +0200, Gary Jennejohn wrote:
> 
> Michael Nottebrock writes:
> > This is exactly why we need more fine-grained (slave-)-ports that translate
> > features into binary packages which can be added and removed easily. If a
> > user asks "How can I get this or that feature in $package" and the answer is
> > "you need install the ports-collection, set some option and then recompile
> > the port" it means that the port is flawed and a slave-port which translates
> > the feature into a binary package is needed.
> > 
> 
> 
> You're joking, right? I certainly am not prepared or willing to make a
> slave port for every twinkie option in the ports which I maintain! Not
> to mention the explosion in the number of files in the ports tree.

Especially when you consider ports like multimedia/mplayer which has
over 20 different options that are independent of each other.  If you
want a slave-port for each (valid) combination of options, you would
need over 2^20 different slave ports.  Adding a million extra
slave-ports just to make sure that nobody ever needs to recompile a
port instead of using a binary package is just not realistic.

Personally I tend to think there are too many slave-ports already which
just take up a lot of space in the ports-tree and make updating the
ports-tree go slower, but then I almost never use binary packages but
build everything from source. (I.e. I would probably barely notice if
all binary packages suddenly disappeared never to return.)


-- 
<Insert your favourite quote here.>
Erik Trulsson
ertr1013 at student.uu.se