suggestions for ports screening

[Chuck Robey]

May as well get all my bright ideas out and over with, all at once.  You 
see, I've spent the last few years exploring other OSes, and finally 
decided I was right, way bakc when I was running FreeBSD to begin with. 
  BUT I have to admit that I saw several good ideas while I was out and 
about.  I have never seen a better package system (at least, in my own 
opinion, you understand) than FreeBSD ports, BUT the methodology for 
qualifying dependencies isn't as good as some I've seen, so I wanted to 
open a discussion about this.  If, at the end of this, no one agrees, 
all I ever ask is that folks give a listen, NOT that anyone actually 
agrees, so I will happily fold up my tent and slink away.

Anyhow, here's the suggestion.  The system we have, currently, is 
basically dependent on people who write ports instrumenting options to 
include or not include various options.  A very large portion of those 
options are written up in such a way as to make it nearly impossible for 
a non-expert to figure out if a particular option is good for their use 
of not.

An example?  If a programmer asks you if you want the blotz program (I 
make up great fake names, don't I?) hows the user going to know the the 
blotz program is a particular sound program, when they have no sound card?

There are ways to fix this, you know.  Read on.

OK, My suggestion is for a two level system (yes, some of you are going 
to recognize some of this from other OSes.  G'wan, brag about it).  The 
first part is a small list of keywords (well, not terribly small, maybe 
100-200 of them, but most user's personal lists would be far shorter). 
These words are descriptive of the sort of machine environment the user 
wants, like, they might have the words SOUND, FMRADIO and TELEVISION to 
show that they care to have those sort of dependencies built.  All ports 
would be required to export a list of words that they check for, before 
they  build.  If a browser sees no SOUND word, it requires to sound 
dependencies be built.  Let me repeat this to get it clearly: the words 
are used to qualify the dependcency lists, but if a particular port is 
chosen, then it gets built, period.  If a user asks for that sound 
program explicitly, then it gets built, SOUND word or no SOUND word. 
It's the dependency lists that have to check and modify themselves.

These dependencies can show up on the list in the form of KEYWORD=VALUE, 
where value can be used to point towards a user's preference.  A user 
might set BROWSER=www/seamonkey,www/mozilla in the list, so this gives a 
port all the info it would need to match dependencies nicely, without 
having to get interactive about it.

OK, this is only the first part ... the second part is a list of the 
names of ports.  This REJECT list serves as a rejection filter: if a 
port finds it's way upon that list, it can't get put on any dependency 
list at all.  I, personally, never like any Samba ports, so I could 
stick all the Samba ports on the REJECT list, or I could just fail to 
put SAMBA as a keyword.  My choice, although if I stuck a particular set 
of ports on that list, I'd have to watch new ports, so  new Samba port 
didn't sneak past me.  Still, it would allow a user to really have all 
the control anyone could ask for. or they could ignore it and still not 
face disaster as long as they maintained the KEYWORD list.

3 stale to the first programmer who notices where I stole the idea from, 
and a used mousetrap to him (or her?) who knows the correct name of the 
KEYWORD list.  If you hate the idea, just say so, believe me I will be 
catching all responses, and I will report your overwhelming acceptance 
or rejection, as the case may be.  It shouldn't take a master's degree 
to guess my own opinion.