Date: Wed, 16 Mar 2005 01:03:49 +0100 From: Michael Nottebrock <michaelnottebrock@gmx.net> To: freebsd-ports@freebsd.org Cc: Andy Fawcett <andy@athame.co.uk> Subject: Re: complaint Message-ID: <200503160103.55083.michaelnottebrock@gmx.net> In-Reply-To: <20050315164021.C84655@april.chuckr.org> References: <20050315145741.H84655@april.chuckr.org> <200503152304.05248.andy@athame.co.uk> <20050315164021.C84655@april.chuckr.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart61719512.OBTkXOtX3e Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday, 15. March 2005 22:56, Chuck Robey wrote: > My own suggestion? Every port have an OPTIONS list, which is a variable > that lists EVERY available makefile option, and naming be such that their > use should be opbvious. Well, the ports that do use OPTIONS are self-documenting already. Not every= =20 port has been converted yet of course. > Maybe, if it's not going too far, add a target=20 > that lists, port by port, the available options. I personally think we > should have fewer ports of higher quality. Not a good approach. The trouble with compile-time switches that trigger=20 dependencies is that they do not translate to binary packages. And the=20 reverse approach - make a (slave-)port per option that changes dependencies= =20 isn't desirable either - at least plenty of people have voiced the opinion= =20 that this would result in just too many ports with too little gain in the=20 past. =46urthermore, most software just isn't designed to be easily compiled piec= emeal=20 in an automated fashion - some software isn't even designed to deal with=20 adding and removing optional parts of it arbitrarily. You probably guessed = it=20 by now: KDE's CUPS support is design-flawed like that. That's why=20 kdelibs-nocups is the best we can do about it right now. And that's why it is indeed hard and difficult, more often than not, to do= =20 these things. The reasonable approach here is to identify where there's enough user-inter= est=20 in more granularity (easy enough to do, the complaints usually arrive by=20 mail-to-maintainer), analyze the feasibility of providing it, and then=20 eventually do it. The unreasonable approach is, if I may say so, wide-sweeping bitching about= =20 some allegedly easy-to-solve-yet-totally-not-addressed problems. The OPTION= S=20 framework does exist and is in use and port-maintainers are usually=20 cooperative when presented with legitimate concerns and reasonable proposal= s=20 made in the spirit of teamwork. =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 --nextPart61719512.OBTkXOtX3e Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCN3frXhc68WspdLARAjHuAJ9IRPIyWPJ3biHZiyl7B8asb4+2+ACcCiVz WzBo9vw1YDNLaklUMfZgWDo= =Fal+ -----END PGP SIGNATURE----- --nextPart61719512.OBTkXOtX3e--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200503160103.55083.michaelnottebrock>