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>