RW wrote:
On Mon, 12 Nov 2007 16:10:29 -0500
Chuck Robey <[EMAIL PROTECTED]> wrote:

I hope not.  We really need to move this out of being a ports
buildtime thing.  Currently, to build ports in batch either requires
someone to be chained to the computer, so as to intercept all those
screens, or to simply agree to install everything, with no inpput
whatever.

This discussion has unfortunately jumped out or ports (wjhere I believe it should have been) to questions, so I have to re-state stuff I've already said. Darn.

Well. I want to explain one of the most important features. First thing, I have to stress I m talking about my writing a character-based tool that carefully guides the user into making the best choice of a limited set of words, to describe their chosen machine environment. I'm NOT going to ask (as Gentoo does) the user to select their own set of words. Gentoo expends damn little help on installation in general, and more specifically, on the maintenance of their USE lists. Their concept of the USE lists is what's important, not their implementation.

Let me give a real-life example. In doing a database of users, you would normally include a file (or lookup table) of state names & abbreviations. This isn't because you're confused about the spelling of Ohio, it's so that, in sorting, you don't jhave to deal with 14 different ways to abbreviate Missouri. You want to be able to sort on one spelling, and not lose half of your Missourian users because they can't agree on a spelling, you want to limit what they use to define their state. OK, you (as programmers) must understand that concept, and the machine environment keyword descriptions (I need a good name for them, and I don't want to use USE because Gentoo uses it, and I don't want to be misunderstood as being the same thing as Gentoo).

If I make a nice database-like program that helps out a user in choosing the best way to describe their system goals, using a limited set of standard words, and set it up so this is done as part of installation. 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.

OK, the good things that accrue from this:

1) list items are always presented right alongside the verbal definitions of what each word semantically means in context. People could still get it screwed up, but that would certainly happen less often.

2) because the number of choices is limited to those on the list, and new items must be filtered thru the ports-management, getting the names wrong or confused is under far better control. There will no longer be 6 ways to define "Music program with mp3's only".Adding a particular option to that music program, say, adding ability to play back AAC songs, would just mean adding the correct keyword. This would allow, some time in the future (not something I'm immediately considering) to do a global scan, with adding some new keyword, to bring one's entire system back up to date. This is not possible today.

2) Since choices are made one per each machine particular, the number of choices is less that a tenth the size of a list of the peer-port dependency choices, setting this up in advance becomes a task that is quite reasonable todo in advance of building all ports. Currently, the sheer idea of setting all options in advance is ridiculous.

3) Choices are made of items that can easily be performed by users without extensive documentation. Trying to inform users of the actual meaning of each and every one of the currently used dependency options would be too complicated a task to expect all users to be able to do this. Informing them of the setup for their particular machine is a far smaller task, one that is small enough to contemplate performing. Describing this in another way, the options will be defined by function, and no longer by the name of the software.

4) Since dependencies are listed by machine environment, and not by port, adding a new port with a correct optioned set of dependencies becomes far more reasonable: merely grep out all ports with a particular set of keywords, and then a ports-writer knows perfectly well what ports they would need to consider as dependency choices. Doing it now, is largely a matter of luck.

I left out one last point> there will be a reject list: a list of port names or regular expression patters, of ports that can't be installed under any circumstances.
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to