Ports with GUI configs

[Chuck Robey]

RW wrote:
> On Mon, 12 Nov 2007 16:10:29 -0500
> Chuck Robey <chuckr at chuckr.org> wrote:
> 
>> I hope not.  We really need to move this out of being a ports
>> buildtime thing.  Currently, to build ports in batch either requires
>> someone to be chained to the computer, so as to intercept all those
>> screens, or to simply agree to install everything, with no inpput
>> whatever. 

This discussion has unfortunately jumped out or ports (wjhere I believe 
it should have been) to questions, so I have to re-state stuff I've 
already said.   Darn.

Well. I want to explain one of the most important features.  First 
thing, I have to stress I m talking about my writing a character-based 
tool that carefully guides the user into making the best choice of a 
limited set of words, to describe their chosen machine environment.  I'm 
NOT going to ask (as Gentoo does) the user to select their own set of 
words.  Gentoo expends damn little help on installation in general, and 
more specifically, on the maintenance of their USE lists.  Their concept 
of the USE lists is what's important, not their implementation.

Let me give a real-life example.  In doing a database of users, you 
would normally include a file (or lookup table) of state names & 
abbreviations.  This isn't because you're confused about the spelling of 
Ohio, it's so that, in sorting, you don't jhave to deal with 14 
different ways to abbreviate Missouri.  You want to be able to sort on 
one spelling, and not lose half of your Missourian users because they 
can't agree on a spelling, you want to limit what they use to define 
their state.  OK, you (as programmers) must understand that concept, and 
the machine environment keyword descriptions (I need a good name for 
them, and I don't want to use USE because Gentoo uses it, and I don't 
want to be misunderstood as being the same thing as Gentoo).

If I make a nice database-like program that helps out a user in choosing 
the best way to describe their system goals, using a limited set of 
standard words, and set it up so this is done as part of installation. 
This makes a little file of descriptor words, but it's not set so a 
regular editor can manipulate it; the special ports program is needed to 
set or reset this list.  All ports query this list in making the 
decision as to whether or whether not to include a particular port as a 
dependency.

OK, the good things that accrue from this:

1) list items are always presented right alongside the verbal 
definitions of what each word semantically means in context.  People 
could still get it screwed up, but that would certainly happen less often.

2) because the number of choices is limited to those on the list, and 
new items must be filtered thru the ports-management, getting the names 
wrong or confused is under far better control.  There will no longer be 
6 ways to define "Music program with mp3's only".Adding a particular 
option to that music program, say, adding ability to play back AAC 
songs, would just mean adding the correct keyword.  This would allow, 
some time in the future (not something I'm immediately considering) to 
do a global scan, with adding some new keyword, to bring one's entire 
system back up to date.  This is not possible today.

2) Since choices are made one per each machine particular, the number of 
  choices is less that a tenth the size of a list of the peer-port 
dependency choices, setting this up in advance becomes a task that is 
quite reasonable todo in advance of building all ports.  Currently, the 
sheer idea of setting all options in  advance is ridiculous.

3) Choices are made of items that can easily be performed by users 
without extensive documentation.  Trying to inform users of the actual 
meaning of each and every one of the currently used dependency options 
would be too complicated a task to expect all users to be able to do 
this.  Informing them of the setup for their particular machine is a far 
smaller task, one that is small enough to contemplate performing. 
Describing this in another way, the options will be defined by function, 
and no longer by the name of the software.

4) Since dependencies are listed by machine environment, and not by 
port, adding a new port with a correct optioned set of dependencies 
becomes far more reasonable: merely grep out all ports with a particular 
set of keywords, and then a ports-writer knows perfectly well what ports 
they would need to consider as dependency choices.  Doing it now, is 
largely a matter of luck.

I left out one last point> there will be a reject list: a list of port 
names or regular expression patters, of ports that can't be installed 
under any circumstances.