suggestions for ports screening

[[LoN]Kamikaze]

Chuck Robey wrote:
> ...

This might either turn into a bikeshed or a creative brainstorming. I hope for
the latter, so I take part.

> 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.

My rule of thumb is to stick to the defaults if I don't know what I'm doing. I
think that could be put mentioned in the handbook, just to make beginners feel
more confident about what they're doing.

> 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?

That problem really exists, though.

> 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.

I like the sound of that. It might be a bigger change that would have to be
implemented into ports over a long period of time. And of course it would only
appear in ports where maintainer are willing to spend the time to support it.

> 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.

How would you deal with cases in which following the users wishes is not
supported. What if a user has SOUND=direct defined to tell programs to use
/dev/dsp instead of a sound server like arts or estd? Most KDE applications
only work with arts, no matter how much you wish otherwise.

> 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.

That's kinda possible already.

.if ${.CURDIR:M*/ports/*samba*}
IGNORE= I don't like samba!
.endif

This would keep everything with samba in the name from being built. I don't
know how the depending ports would react to that, though.

> 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.

I came over from an OS without a package system (Windows), so I've got no idea
where you took all that from.