Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 16 Oct 2004 14:58:21 +0200
From:      Michael Nottebrock <michaelnottebrock@gmx.net>
To:        Erik Trulsson <ertr1013@student.uu.se>
Cc:        freebsd-ports@freebsd.org
Subject:   Re: alternative options for ports
Message-ID:  <200410161458.25304.michaelnottebrock@gmx.net>
In-Reply-To: <20041016121159.GA41657@falcon.midgard.homeip.net>
References:  <michaelnottebrock@gmx.net> <200410161331.01356.michaelnottebrock@gmx.net> <20041016121159.GA41657@falcon.midgard.homeip.net>

next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart2882875.EuAn78x9a2
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Saturday 16 October 2004 14:11, Erik Trulsson wrote:

> 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.

Yes.

> You know what - that is exactly how things mostly work today,=20

No. There are still a lot of ports which do things like installing perl/pyt=
hon=20
bindings via build switches, which is a packaging pain (and causes dependen=
cy=20
trees of other ports to become way bigger than necessary) to name just one=
=20
example. OPTIONS has, unfortunately, helped those kind of ports to survive=
=20
even longer.

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

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.

There's nothing that amounts to "packages are a just a nice bonus" in those=
=20
quotes. Even if there were, it would just be a documentation bug.
The last sentence in fact is a documentation bug, because it's an=20
overgeneralization. It very much depends on what exactly is ported/packaged=
 -=20
not every application is as badly designed (monolithic) as MPlayer.

=2D-=20
   ,_,   | Michael Nottebrock               | lofi@freebsd.org
 (/^ ^\) | FreeBSD - The Power to Serve     | http://www.freebsd.org
   \u/   | K Desktop Environment on FreeBSD | http://freebsd.kde.org

--nextPart2882875.EuAn78x9a2
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.9.10 (FreeBSD)

iD8DBQBBcRrxXhc68WspdLARAonNAJ0ZlM7n7w4nUlLboU8KtXyKzCu5agCffCMG
XOK64z9Vabt7weK5KCYPGEw=
=M+i0
-----END PGP SIGNATURE-----

--nextPart2882875.EuAn78x9a2--



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