Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Oct 2004 03:50:34 +0200
From:      Erik Trulsson <ertr1013@student.uu.se>
To:        Michael Nottebrock <michaelnottebrock@gmx.net>
Cc:        freebsd-ports@freebsd.org
Subject:   Re: alternative options for ports
Message-ID:  <20041016015034.GA92507@falcon.midgard.homeip.net>
In-Reply-To: <200410152156.16113.michaelnottebrock@gmx.net>
References:  <michaelnottebrock@gmx.net> <200410151404.i9FE4Jrc006244@peedub.jennejohn.org> <20041015141551.GA80394@falcon.midgard.homeip.net> <200410152156.16113.michaelnottebrock@gmx.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Oct 15, 2004 at 09:56:11PM +0200, Michael Nottebrock wrote:
> On Friday 15 October 2004 16:15, Erik Trulsson wrote:
> > 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 at all. If there is a feature that is of potential interest for a great 
> number of users and is not enabled by default in the package, you should very 
> seriously consider making a packagable port for it.

That is not quite the same thing as making a slave-port for every
option, or combination of options, for every port, but almost since
most features are of *potential* (but probably not actual) interest to
a great number of users. Doing so is neither practical nor realistic.


> 
> 
> >
> > 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.
> 
> Look at Debian and tell me again it's not realistic. And I'm not suggesting 
> going as far as Debian does.

I don't know what Debian does or does not do, but I don't need to know
that to tell you again that adding a million slave-ports is not
realistic and that anybody who seriously suggests that must be out of
his or her mind. (Yes, I did mean "a million extra slave-ports"
literally, and was not employing hyperbole.)
(Hint: Currently there on the order of 10000 ports. Adding a million
extra ports would increase the size of the ports collection
hundredfold, and the package building would probably not be able to
finish until it is time to start over again for the next release.
That million slave-ports is just what would be needed for
multimedia/mplayer. Then there are all the other ports as well.
Not realistic is a vast understatement. Completely insane would be
closer.)

> 
> > 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.)
> 
> I realise that there is a fraction of ports users which don't care about 
> packages at all (and could be using gentoo just as well), but they are not 
> the primary target audience of ports, as I pointed out before.

No, they could not be using gentoo just as well, since that is a Linux
distribution (AFAIK) which is not the same thing as FreeBSD.

I view the building from source as the primary purpose of the ports
system, with the creation of binary packages as just a nice bonus.

It is after all necessary to compile from source in order to be able to
build a binary package, but it is not necessary to be able to create a
binary package in order to compile from source, which suggests that the
compilation step is the more fundamental and important one.
There are also several ports which for legal reasons can't be
distributed as binary packages, which again requires you to install the
ports-tree and compile from source.

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041016015034.GA92507>