Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Oct 2004 14:11:59 +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:  <20041016121159.GA41657@falcon.midgard.homeip.net>
In-Reply-To: <200410161331.01356.michaelnottebrock@gmx.net>
References:  <michaelnottebrock@gmx.net> <200410152156.16113.michaelnottebrock@gmx.net> <20041016015034.GA92507@falcon.midgard.homeip.net> <200410161331.01356.michaelnottebrock@gmx.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Oct 16, 2004 at 01:31:00PM +0200, Michael Nottebrock wrote:
> On Saturday 16 October 2004 03:50, Erik Trulsson wrote:
> 
> > 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.)
> 
> I have no idea how you're arriving at the number of a million slave ports. I 
> have no idea how you could think I was suggesting adding a million slave 
> ports (however one would achieve that, I have no idea) either.

Then you did not read what I wrote earlier.  I used multimedia/mplayer as
an example.  That port has (over) 20 independent options.  Since each of
those 20 options can be set or not set there are 2^20 == 1048576
different combinations of options which can be chosen. 
If you do not add all those combinations as slave-ports, then there
will be some (perfectly reasonable) configurations of
multimedia/mplayer that do not have a corresponding package and will
require people to recompile from ports.

Although mplayer is a somewhat extreme example there are many other
ports that also have several independent options, and would also
require a large number of slave-ports to cover all configurations.

(I think the relevant phrase here is "combinatorial explosion".)

> 
> > (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.
> 
> That's utter nonsense. The easiest way of providing a good package for a port 
> is: Turn as many optional features/build-switches on by default. In some 
> cases, turning something on isn't desirable because it adds too many 
> dependencies to a package which people would not usually want. For _those_ 
> cases, it is a good idea to investigate if slave ports can be made so the 
> features are available to package users immediately. If that's not possible, 
> tough luck - at least for the moment, because a good port maintainer would 
> then go and try to nudge upstream development into making the application 
> modular enough to make it possible in the future.

So what you are saying is that of the existing options in a port, those
which makes sense to have turned on by default should be turned on by
default.  If there are some option that lots of people wants turned on,
while lots of other people wants turned off, you can add a slave-port for
that option.
You know what - that is exactly how things mostly work today, so if
that is how you want things work there is no need to change anything.

The problems occur when you want to add a slave-ports for *all* (or
even most) port-configurations and not only the most common ones.
The number of slave-ports needed (and the corresponding number of
packages that has to be built) will increase very rapidly.


> 
> > 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.
> 
> With all due respect for your view, but that's just not true.

It isn't?
>From the FreeBSD handbook (section 4.2):

   A FreeBSD port for an application is a collection of files designed
   to automate the process of compiling an application from source
   code.
[...]
   In fact, the ports system can also be used to generate packages
   which can later be manipulated with pkg_add and the other package
   management commands that will be introduced shortly.
[...]
       In some cases, multiple packages will exist for the same
       application to specify certain settings. For example,
       Ghostscript is available as a ghostscript package and a
       ghostscript-nox11 package, depending on whether or not you have
       installed an X11 server. This sort of rough tweaking is possible
       with packages, but rapidly becomes impossible if an application
       has more than one or two different compile time options.



All of which seems to agree completely with what I have said.


-- 
<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?20041016121159.GA41657>