Ports with GUI configs

Chuck Robey chuckr at chuckr.org
Fri Nov 16 11:13:26 PST 2007

Chad Perrin wrote:

I personally felt we'd sufficiently discussed this to death, but now 
there's 2 different folks who want to tear it apart some more.  If 
you're bored of this, tell me, and I will drag these folks either into 
private discussions, or maybe onto the ports list.  Tell me if you've 
heard enough of this .....

Read below for my comments.

> On Thu, Nov 15, 2007 at 10:56:12PM -0500, Chuck Robey wrote:
>> Chad Perrin wrote:
>>> On Thu, Nov 15, 2007 at 03:34:26PM -0500, Chuck Robey wrote:
>>>> Chad Perrin wrote:
>>>>> On Mon, Nov 12, 2007 at 08:23:23PM -0500, Chuck Robey wrote:
>>>>>> 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.
>>>>> Ugh.  As far as I'm concerned, everything that pertains to system
>>>>> configuration should always be human-readable and editable without
>>>>> special tools.  Trying to insulate things from human ability to directly
>>>>> manipulate them tends to lead to rapidly increasing difficulty of
>>>>> debugging configurations.
>>>> I might have agreed with this, except, I have lived for a good while 
>>>> with the Gentoo "USE" lists, and I can tell you that having insufficent 
>>>> control over what goes ontp those lists causes havoc both with the users 
>>>> trying to select the proper wording of the lists, and the programmers 
>>>> trying to decide how to have a particular USE keyword represent a 
>>>> particular ports usage.  You have to make certain that both users and 
>>>> programmers have a definite, firm meaning in mind when they use the 
>>>> keywords, because (in another's well chosen words) if you don't, USE 
>>>> lists are a PITA.  It takes firmer control of meaning to make certain 
>>>> that the list doesn't devolve into that.
>>>> This is actual experience talking, in this case.
>>> I don't see how that translates into "the user should not be allowed to
>>> view what's going on behind the scenes in a text editor if (s)he wants
>>> to."
>> I think you're becoming confused about who said what, because that 
>> particular line (the last paragraph above) isn't anything that I wrote.
> Quote:
>   This makes a little file of descriptor words, but it's not set so a 
>   regular editor can manipulate it
> That's the point I'm addressing.  No more, and no less.  The response I
> received to addressing that did not seem to provide much support for that
> quoted statement, so I let you know that I don't see how that translates
> to "the user should not . . ." et cetera.

It's because, in actual experience with a system based upon usage of 
keywords (a bit more compllicated than what I'm suggesting, but it IS a 
real-life system, specifically Gentoo Linux.  As someone else (I forget 
who) said (and I fully agreed with him), "USE lists are a PITA.  That's 
true.  I can't point with the same agsolute certainty to the reasons 
it's a PITA, I think I know them, but the facts are as I stated. 
Personally, I believe it's because the meanings of the keywords are 
insufficiently standardized.  That's my own opinion, but the fact that 
maintaining USE lists is a PITA is fairly clear.

I want to move all the work of specifying the dependencies used by ports 
from being done at build time to being done at system install time. 
Further, I want to decouple the choosing of actual ports from 
dependencies also ... I want users to say something like "I have no 
audio", and this statement to be coded as NO_AUDIO, and all ports to be 
guided by the settings of the list keeping this info.  I have no name 
for the lists, but I don't want to call them USE lists, because I'm not 
suggesting we slavishly follow Gentoo on this, and using the same name 
would give that impression.  Maybe MACHINE_DEFS, something like that? 
I'm not particularly good at making names.

A second part of this suggestion was a reject list of regular 
expressions, and any ports matched would be ineligible to be built or 

Lastly, my point about making sure that both the users and the ports 
authors use the exact same meanings is, in my opinion, the detail 
missing from the Gentoo implementation, so I'm proposing that the 
maintenanace of the list be done thru a particular tool, which will 
prominently display the actual meaning of the word being set.  The only 
reason to make the list binary is to force everyone to use the 
(basically database technology) tool to manipulate the keywords, thus 
stopping folks from misconstruing the meanings.  That's my only reason 
for that, and there are certainly other ways to go about it, so as long 
as whatever is suggested requires folks to see the commonly accepted 
definition when they set the list, I don't care how it's done.  The list 
could as easily be encrypted, I guess, that would also cause the same 
work flow, in somewhat the same reasoning as we use for forcing folks to 
use "vipw" to change the pasword list.

Please consider that we'll get another chance to argue this out when I 
have the software ready, so we don't need to settle it now.  I don't 
want this to continue to pollute the -questions list.

>> At that point, I will prepare, in advance, use cases, all the 
>> documentation, and the actual code, and everyone will get their chance 
>> to rant and rave, alrighty?  You can stop me cold, if enough folks don't 
>> like the idea, that's how the development of FreeBSD goes, and I 
>> wouldn't change a thing with that.
> I'd rather that you produce software I want than software I don't,
> though.  That's why I tend to feel that it's better to sort out what is
> and isn't wanted, why it is and isn't wanted, and both whether and how
> that applies to what you propose to produce, before it's produced.
> Obviously, I'm not saying that what I personally want should be the
> driving force behind FreeBSD, but from where I'm sitting that's the
> important part.

More information about the freebsd-questions mailing list