Date: Fri, 16 Nov 2007 14:11:57 -0500 From: Chuck Robey <chuckr@chuckr.org> To: FreeBSD Questions <freebsd-questions@freebsd.org> Subject: Re: Ports with GUI configs Message-ID: <473DEB7D.3030508@chuckr.org> In-Reply-To: <20071116151734.GB80515@demeter.hydra> References: <4738ACDD.50108@u.washington.edu> <4738ADC8.2060005@gmx.de> <4738AEBF.4010109@u.washington.edu> <4738C145.2050601@chuckr.org> <20071112214240.5d3b048a@gumby.homeunix.com.> <4738FC8B.5000309@chuckr.org> <20071114230723.GD70122@demeter.hydra> <473CAD52.6060309@chuckr.org> <20071115221638.GC76155@demeter.hydra> <473D14DC.4070104@chuckr.org> <20071116151734.GB80515@demeter.hydra>
next in thread | previous in thread | raw e-mail | index | archive | help
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 installed. 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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?473DEB7D.3030508>