Ports with GUI configs
perrin at apotheon.com
Fri Nov 16 07:17:02 PST 2007
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
> >>>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
> I think you're becoming confused about who said what, because that
> particular line (the last paragraph above) isn't anything that I wrote.
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.
> 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
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
McCloctnick the Lucid: "The first rule of magic is simple. Don't waste your
time waving your hands and hopping when a rock or a club will do."
More information about the freebsd-questions