suggestions for ports screening

[Chuck Robey]

[LoN]Kamikaze wrote:
> Chuck Robey wrote:
>> ...
> 
> This might either turn into a bikeshed or a creative brainstorming. I hope for
> the latter, so I take part.

Yeah, if it looked like a flamebait, I would run for the hills myself, 
but it looks pretty good so far.

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

Problem is, those defaults take absolutely no notice whatever of a 
user's local environment.  It does allow some level of user input, but 
since the way things have been implemented has been totally up to the 
programmer, our system right now is very nearly out of control, as far 
as an unbelieveable level of grabiness for dependencies.  The other day, 
I selected one single port, and when portmanager had completed, ~200 
more things had ben installed.  I'm just saying that we need some system 
that pushes people to do a bit more active screening.

You have also to recognize, it's largely a human, psychological thing 
I'm am trying to manipulate, because our present system if implemented 
100% perfectly, would absolutely do the job.  It's the particular human 
emphasis'es (how do you pluralize emphasis?) that I want to play with.

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

Like I said above, yes, our current system CAN DO the job, but with the 
way that it's pointed, psycolgically, it's doing a particularly poor job 
of it.  We need a change that pushes the level of control, 
psychologically, more towards the user.  I cannot, do not argue that our 
present system can't do the job, I am saying that it isn't doing it.

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

Are you seriously asking all of are tech aznd non-tech users to keep 
track of all the names of any ports that supply a particular 
functionality set (do you really think that all Samba ports have the 
name Samba?  That's silly)  BUT if you required programmers to set the 
correct list of KEYWORDS, then that's a much more obvious and easy to 
check item.
> 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.
> 
I guess, from all the guesses that came in., I maybe better admit where 
I stole this idea... Gentoo's Portage system no other.  I DO NOT propose 
to bring that system in, I really like FreeBSD system, based upon our 
make(7).  But, I do propose to bring in sections of their USE system, 
for qualifying dependencies.

The only other part of their sytem that I really like (but not one I am 
pushing right now) is that they use Python as the implementation 
language.  I like Python a great deal, but I guess that's for another 
day, or maybe another person to champion it.

Again, I am proposing two lists, one of USE keywords (and I couldn't 
care less about using the USE word, so if it bothers you, suggest your 
own, I'm open on that).  There would be a master USE_KEYWORDS list that 
would require you to use words on this list, and would carry as the 
second field in the 2 field list, as a clear text explanation of the 
real meaning of every word.  Words could have either a positive or a 
negative meaning, depending on if the word was prefixed with either a 
plsu (+) or a minus (-) sign.  Second part is a list maintained by each 
user, of the actual name of all ports that cannot be installed under any 
circumstances.  This list would also allow prefixing by +/-, where a 
plus means the user would want the ports system to assume that the port 
was always installed (even though  it would not be installed) so that no 
competitor would be installed, or a minus meaning, it is never to be 
considered to be installed, but another port with equal KEYWORD values 
could be chosen by a port.

As far as implementation goes, Heck, it would be fine to do this 
incrementally, in parallel (for a while) with out current system.  If 
the discussion continues for a few more days without much serious 
complailnts, I will undertake to write up a diff to our current system 
which would implement this.  Other's could do it also, I don't care if I 
write it or if others do, as long as such as system becomes used, one 
that looks like what I'm describing, at least generally looks like it. 
I will try really hard not to be too stubborn about it.  Wouldn't work 
with FreeBSD'ers to be stubborn, our consensus-based approval system 
wouldn't stand for it.

When we get at least one good impelmentation to actually consider, then 
we could look one more time, hard, if we really want to do this.  I know 
there are no guarantees on that, I just didn't want to start doing it, 
if everyone was dead set against it.

So, right now you have the chance to stop me before I get started, but 
not the last chance to stop the idea if you hate it.  I'd appreciate it, 
if you're really dead set against it, speak up now, let me know if there 
are some truly negative aspects of what I'm suggesting that you can't 
stand.  I might either modify what I'm implemting, or even drop the 
idea, if the noise gets loud enough.