Date: Sun, 21 Jul 2002 13:22:47 +0200 From: Neil Blakey-Milner <nbm@mithrandr.moria.org> To: Will Andrews <will@csociety.org> Cc: Simon 'corecode' Schubert <corecode@corecode.ath.cx>, Nik Clayton <nik@FreeBSD.ORG>, ports@FreeBSD.ORG Subject: Re: Proposed new 'options' target Message-ID: <20020721112247.GA44412@mithrandr.moria.org> In-Reply-To: <20020720175640.GI52296@squall.waterspout.com> References: <20020720162928.GD37802@clan.nothing-going-on.org> <20020720190909.458442de.corecode@corecode.ath.cx> <20020720175640.GI52296@squall.waterspout.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat 2002-07-20 (12:56), Will Andrews wrote: > On Sat, Jul 20, 2002 at 07:09:09PM +0200, Simon 'corecode' Schubert wrote: > > that's a good quick hack[tm] but it doesn't prevent the port options > > from being scrolled off screen when building and doesn't increase > > usability very much. > > > > i'll try and come up with a patch in the 32th week which will > > (hopefully) include these features: > > o ask for options via dialog or tcl/tk when port is building > > o if/iff no options were chosen before > > o save options while building and with the package > > o retrieve options from already installed package > > o use options versioning > > > > this would be a major leap towards better usability. with a standardized > > frontend much more ports would be able to support options. > > > > this is my proposal. comments and flames welcome. patches too ;] > > I like it. Does anyone else have implementations they've > finished which have never been committed? I'd like to pick one > and go with it, fix problems later. Right now is a pretty good > time for this kind of thing, since 4.7 is still a few months away. (Warning: It may seem I'm incredibly bitter and twisted over stuff. I'm not really.) Well, there's the implementations I did over 3 years ago that were pretty much ignored despite multiple requests for comment. The sole copy I have left is the one I dislike the most - it's at http://people.FreeBSD.org/~nbm/portconf/ . It features three "clients", a perl script that fakes understanding of XML (since the only comment I got from my RFCs was to use XML), and console and gtk (http://people.freebsd.org/~nbm/portconf/gportconf.jpg) versions written in C that understand "classes" and "depends" (more later). I made later revisions to that version, which introduced conflicts and radio buttons, but that and my previous attempts are long lost. It was eventually part of my gpkgman package manager proof of concept (early screenshot at http://people.freebsd.org/~nbm/gpkgman2.jpeg), prompting for options seemlessly without leaving the package manager before going through the usual fetch, extract, configure, ... cycle (much like pib). Lost that too, unfortunately. Simple positive thoughts from that (negative thoughts available too on request): 1) Allow people to turn it off. Or to optionally always be asked about possible customisation. Or to make a port make a more strenuous argument that it needs to be configured. Was my number one requirement going into this. 2) Don't use XML. Just use something simple like "option|description" in a file. Reserve further '|' things for depends and conflicts and "radio button choices". This was my first design. 3) Initial implementation code should be available on all FreeBSD systems without a port (if possible). I chose perl first - I imagine that will be ok despite it's relocation. My initial concept was in 'sh' calling 'dialog' with the correct arguments, abstracted from the apache (now in mod_php4) example configure script. Because of XML, I then wrote in C (keeping a fake XML perl version). Not sure if that's a good idea in the near future. 4) "Elegant" suggestion: Don't put the code to generate in the options file - use the existing WITH_* stuff and implement in the Makefile. This was my second iteration, but it didn't make it to the C version. Also, the mod_php4 port still doesn't do this. May not be important. 5) Strong suggestion: Implement "classes" of options, with basic classes of "default", "minimum", and "maximum". "default" defaults to "minimum", which defaults to no options chosen. "maximum" defaults to all options chosen. Allow users to specify their classes. If really bored, allow users to create their own classes. This may even be better than "saving" - you need only copy over your /var/portconf directory (or NFS share it), and set your default class choice to "nbm" (for example), and you'll always get your preferred defaults. May allow multiple default class choices, like "nbm rucus minimum", on a first-match basis. 6) Wishful suggestion: Try to standardise option names as much as possible, and allow users to turn certain options on and off by default somewhere. Such as "doc", "ssl", "ipv6", and "kde". In batch mode, don't ask for options, but use the default class choice if available, and if not, use the default option choices. 7) Do it, and don't shut up about it until it's in. Eventually someone else will agree you have a good idea. Don't give up. (Now if only I followed my own advice.) I don't have time in the immediate future for this (historical contribution treatment not motivational either), but if I'm the sole hope for implementation (although I seriously doubt it), someone nudge me in two weeks. Neil -- Neil Blakey-Milner nbm@mithrandr.moria.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020721112247.GA44412>