Re: Ports with GUI configs
On Saturday 17 November 2007 02:06, Chad Perrin wrote: On Fri, Nov 16, 2007 at 02:11:57PM -0500, Chuck Robey wrote: 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. I haven't read the discussion on -ports, but I hope the rest of your (Chuck Robey's) arguments are better founded than this one. No-one forces anyone to use vipw(8). You can, for example, edit /etc/master.passwd or a copy of it with any editor you like, and then run pwd_mkdb(8) to install your changes. vipw just gives you file locking (plus sanity checks and an automatic call to pwd_mkdb). I think forcing anyone to anything is a *bad idea*. Period. You're talking about placing arbitrary limits on what the user can see if he or she wants to understand what's going on under the hood. With that kind of treatment, I would never have learned as much about FreeBSD as I know as quickly as I did. I agree. I, for one, would probably refuse to use such a system once I learned enough about the basics to want to know what it's doing. The moment I figured out it was designed specifically to obscure some aspect of its operation from the user, I'd look for something else to use instead. There are very good reasons for this -- reasons like security, curiosity, and just plain good manners. 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. I'm not at all sure what problem you're trying to solve here. If I know I need to change the defaults on a port, I generally know why and what the implications are; if I don't, the defaults are generally what I need anyway. As far as I can see, you want to remove a deal of flexibility from the ports system, in favour of introducing a compulsory scheme of configuration hints. You say you want to move ports configuration from port install time to system compile time - which in itself is, in my view, an unrealistic objective: it will break the first time a new port has an option which can't be determined on the basis of an existing keyword. Not only that, but it means that as soon as I install a single port (Perl, for example), I would have to run the complete ports-tree configuration routine. I'm sorry to leap on board and prolong the agony at this late stage, but I wanted to add another datum point, particularly given the rather dismissive 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 . Jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
On Thu, 15 Nov 2007 21:58:35 -0500 Chuck Robey [EMAIL PROTECTED] wrote: ed to take exception to that. My claim (and I have the messages in which I made it) is that the setting of options needed these changes: (1) To move the time that they need to be set, from ports compile time to system install time, and ... I think (I may be wrong, correct me if I am) that you were taking exception, above, to my first point, right? You may correct me on that, but on whether or not it will actually succeed in this is what all this discussion is about. I did not bring this up without bringing the idea past local friends, and defending it there, so I think I can do that. Do i need to requote all of my arguments about that here Of course I've read them. They are about dependencies, but port options are also about the internals of ports. Even if all dependency management were take out of port options, it wouldn't have a significant impact on the number of ports that use port options. ... they will 100% move the work from ports build-time to system install-time. This is pretty simple to prove, so I can't follow your assertion, If it is pretty simple to prove, you wont mind telling me how your system could determine at system install time, whether I will want squid built with AUFS support - even if I don't know much about squid it the time. It's a simple question. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
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. 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. -- 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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
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
Re: Ports with GUI configs
On Fri, Nov 16, 2007 at 02:11:57PM -0500, Chuck Robey wrote: 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. I think forcing anyone to anything is a *bad idea*. Period. You're talking about placing arbitrary limits on what the user can see if he or she wants to understand what's going on under the hood. With that kind of treatment, I would never have learned as much about FreeBSD as I know as quickly as I did. I, for one, would probably refuse to use such a system once I learned enough about the basics to want to know what it's doing. The moment I figured out it was designed specifically to obscure some aspect of its operation from the user, I'd look for something else to use instead. There are very good reasons for this -- reasons like security, curiosity, and just plain good manners. 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. I'm rapidly running out of enthusiasm for bothering to look at it once it's done. Systems I can't study are systems I don't like, generally. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] Ben Franklin: As we enjoy great Advantages from the Inventions of others we should be glad of an Opportunity to serve others by any Invention of ours, and this we should do freely and generously. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
[LoN]Kamikaze wrote:
Chuck Robey wrote:
RW wrote:
On Mon, 12 Nov 2007 22:54:33 +0100
Tino Engel [EMAIL PROTECTED] wrote:
RW schrieb:
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.
That's not correct, you can run make config-conditional or make
config-recursive anytime you like.
But not on a portupgrade... I don't want to run config-recursive on
the whole ports tree though
It's not hard to script it though, something like the following would do
#!/bin/sh
for p in `pkg_version -ol'' |awk '{ print $1 }'`; do
cd /usr/ports/${p} make config-recursive done
I can't believe you actually suggested this. First thing, it would take
you HOURS to complete, and you better not make even one mistake, 'cause
you couldn't even go back far enough to figure out what the name was of
the port you muffed. Beyond that, since most ports ask questions formed
with the name of the target dependency, aznd not asking things like do
you want such-and-such capability, so you have to be conversant with
the names and capabilities of nearly 10,000 ports, to be able to do that
job.
It will only operate on 1 ports if you have 1 ports installed and a
majority of them is outdated.
Are you seriously saying that a decision regarding what ports are to be
installed should be made after they are installed? If you have 10,000
ports installed, you obviously have no need whatever to make any
decision at all. Whether or not they are outdated is utterly
irrelevant, because if they're installed, it may be inferred that you
wanted them. It's the decision whether to install them or not that
we're talking about.
Upgrading has no bearing whatever on this. Why do you bring that up?
I'm of the impression that you don't really know what the commands do you're
shown here and come to ridiculous conclusions because of this.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
[LoN]Kamikaze wrote: Chuck Robey wrote: Garrett Cooper wrote: [LoN]Kamikaze wrote: Garrett Cooper wrote: USE flags are a pain in the ass (former Gentoo user of 3 years). Introducing that type of complexity into a ports system isn't necessary and does unexpected things at times for end-users when developers change variable names or behavior, which happened quite often with Gentoo. make config-all or something similar to have people fill in their desired config info in all of the ncurses config sections would however be a much better idea I think.. -Garrett Are you talking about make config-recursive? Yes =\. Lemme guess.. that's already an option :)? 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. These are both bad options. No, you got it wrong. You run 'make config-recursive' and get all the configure screens at once. Afterwards you can just run 'make install clean' and go away. Read the ports(7) manpage. Oh, (I just erased a bunch, I should never use sarcasm, even when it's deserved). Do you have the 3 weeks it would take, to sit down and run thru all the configs for 10,000 ports? I don't know how many, exactly, but you'll have to agree it's huge. On top of this obviously ridiculous task, you would need to do a huge amount of investigation, because most of these option questions don't give nearly enough info to have anyone excepting 1% of the techies to be able to make reasonable decisions. OTOH, a well organized database describing a user's machine environment and their personal proclivities IS easily possible, and would cause all that decision making to be done automatically. For the great majority of users, it's a far, far better option. The sticky point, the one that needs to be done with psychological care, is to make it possible for non-technical users to correctly define their wants. Get that part correct, and then you have a nicely workable system that ports writers can use to guide their port's dependency decisions. If you're using sysutils/bsdadminscripts you can run 'portconfig-recursive -a' before a 'portupgrade -a' in order to avoid having someone sit in front of the machine during the portupgrade. Only if you are choosing some default value, we have no other system in place to be able to define what decisions to make. If you are proposing such a system, well, that's precisely what I'm doing. Otherwise, you face users with a gigantic task, answering questions that they are not equipped to answer. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
Chuck Robey wrote:
[LoN]Kamikaze wrote:
Chuck Robey wrote:
RW wrote:
On Mon, 12 Nov 2007 22:54:33 +0100
Tino Engel [EMAIL PROTECTED] wrote:
RW schrieb:
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.
That's not correct, you can run make config-conditional or make
config-recursive anytime you like.
But not on a portupgrade... I don't want to run config-recursive on
the whole ports tree though
It's not hard to script it though, something like the following
would do
#!/bin/sh
for p in `pkg_version -ol'' |awk '{ print $1 }'`; do
cd /usr/ports/${p} make config-recursive done
I can't believe you actually suggested this. First thing, it would take
you HOURS to complete, and you better not make even one mistake, 'cause
you couldn't even go back far enough to figure out what the name was of
the port you muffed. Beyond that, since most ports ask questions formed
with the name of the target dependency, aznd not asking things like do
you want such-and-such capability, so you have to be conversant with
the names and capabilities of nearly 10,000 ports, to be able to do that
job.
It will only operate on 1 ports if you have 1 ports installed
and a
majority of them is outdated.
Are you seriously saying that a decision regarding what ports are to be
installed should be made after they are installed? If you have 10,000
ports installed, you obviously have no need whatever to make any
decision at all. Whether or not they are outdated is utterly
irrelevant, because if they're installed, it may be inferred that you
wanted them. It's the decision whether to install them or not that
we're talking about.
Upgrading has no bearing whatever on this. Why do you bring that up?
We're talking about a suggested shell script that calls config-recursive for
outdated ports. I did not bring that up.
I'm out of this. It's a bikeshed after all.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
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 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. I *love* this idea! /me starts cobbling together a list of things that start with 'k' or 'g', preparing for that future date when this is possible. Yes, that was my own feeling. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
RW wrote: On Thu, 15 Nov 2007 14:55:02 -0500 Chuck Robey [EMAIL PROTECTED] wrote: Are you seriously saying that a decision regarding what ports are to be installed should be made after they are installed? If you have 10,000 ports installed, you obviously have no need whatever to make any decision at all. Whether or not they are outdated is utterly irrelevant, because if they're installed, it may be inferred that you wanted them. It's the decision whether to install them or not that we're talking about. What you don't appear to understand is that the Option Framework allows a user to recursively set options for ports *before* they are installed. So to configure the whole of Gnome, you can simply do this: # cd /usr/port/x11/gnome2 make config-recursive The reason I mentioned the script is that upgrades are the only part of the process that isn't directly supported by the ports system, you need something to catch the ports that have changed options, or you may waste time. This requires a script, but new installs are completely trivial. I've already deleted the message that kicked me off, but it looked to me that you were talking about the 10,000 ports I was talking about, and that meant you were referring to new installs, not upgrades. If it were me, I would think that upgrades should probably follow the same path as the original install, no? In some small number of cases, there would be brand new options that would not be possible to predict from the decisions already taken for the orignal system, but that would be the exception, not the rule. Regardless, as an unintended side effect of the system I'm talking about, such items would be automatically taken care of. The only recurring task would be, as new options find themselves required, users would be asked to register the setting for a new keyword. This would probably mean something on the order of maybe one or two new words a month to decide on, something that would hardly be a worry. I do agree, the system I'm talking about, if I was trying to justify it only on the basis of upgrades alone, would not be justified. Sort of like the tail wagging the dog, too much work for too little gain, but as a nice side effect, it's acceptable. BUT if you were talking only about upgrades, then I kinda think, personally, that you probably should instantiated a new thread, not used this one. Hmm? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
[LoN]Kamikaze wrote: Upgrading has no bearing whatever on this. Why do you bring that up? We're talking about a suggested shell script that calls config-recursive for outdated ports. I did not bring that up. I'm out of this. It's a bikeshed after all. OK, I can agree with that. I let my mail pile up a little, and finally caught the last few of these, but I'm finished. We'll get back to arguing on it when I get something coded up. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
On Thu, 15 Nov 2007 14:55:02 -0500 Chuck Robey [EMAIL PROTECTED] wrote: Are you seriously saying that a decision regarding what ports are to be installed should be made after they are installed? If you have 10,000 ports installed, you obviously have no need whatever to make any decision at all. Whether or not they are outdated is utterly irrelevant, because if they're installed, it may be inferred that you wanted them. It's the decision whether to install them or not that we're talking about. What you don't appear to understand is that the Option Framework allows a user to recursively set options for ports *before* they are installed. So to configure the whole of Gnome, you can simply do this: # cd /usr/port/x11/gnome2 make config-recursive The reason I mentioned the script is that upgrades are the only part of the process that isn't directly supported by the ports system, you need something to catch the ports that have changed options, or you may waste time. This requires a script, but new installs are completely trivial. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
On Thu, 15 Nov 2007 16:00:55 -0500 Chuck Robey [EMAIL PROTECTED] wrote: I've already deleted the message that kicked me off, but it looked to me that you were talking about the 10,000 ports I was talking about, and that meant you were referring to new installs, not upgrades. Why would anyone want to configure ports they don't want to install? BUT if you were talking only about upgrades, then I kinda think, personally, that you probably should instantiated a new thread, not used this one. Hmm? Is that supposed to irony, because before you hijacked this thread it was about preventing options screens being brought up at build-time, and pausing the build. Your ideas do absolutely nothing to address this issue because, they would only reduce the number of options, not eliminate them - unless you are intending to radically dumb-down the system. As a case in point take a look at the options for www/squid, I don't believe for a moment that your scheme could handle more than a small fraction of them. If people want an easier desktop system, they already have the pc-bsd and DesktopBSD versions of FreeBSD. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
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. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] W. Somerset Maugham: The ability to quote is a serviceable substitute for wit. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
On Thu, Nov 15, 2007 at 09:43:16PM +, RW wrote: On Thu, 15 Nov 2007 16:00:55 -0500 Chuck Robey [EMAIL PROTECTED] wrote: I've already deleted the message that kicked me off, but it looked to me that you were talking about the 10,000 ports I was talking about, and that meant you were referring to new installs, not upgrades. Why would anyone want to configure ports they don't want to install? I've been following this discussion without participating, but I have a question: How does that question follow from the preceding, quoted statement? -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] John Kenneth Galbraith: If all else fails, immortality can always be assured through spectacular error. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
On Thu, Nov 15, 2007 at 11:15:56PM +, RW wrote: On Thu, 15 Nov 2007 15:04:07 -0700 Chad Perrin [EMAIL PROTECTED] wrote: On Thu, Nov 15, 2007 at 09:43:16PM +, RW wrote: On Thu, 15 Nov 2007 16:00:55 -0500 Chuck Robey [EMAIL PROTECTED] wrote: I've already deleted the message that kicked me off, but it looked to me that you were talking about the 10,000 ports I was talking about, and that meant you were referring to new installs, not upgrades. Why would anyone want to configure ports they don't want to install? I've been following this discussion without participating, but I have a question: How does that question follow from the preceding, quoted statement? I assumed that he meant all ports, 10,000 is of the same order of magnitude as the total number of ports (27000), but an absurdly high figure for a real system. Actually the total number of ports in the entire tree that support options is only 1447. And out of 821 ports installed on my KDE desktop machine only 140 do. The idea that anyone ever has to configure 10,000 ports is nonsense. Ah, thank you. Somehow, I missed that implication (even though I personally have far, far fewer ports installed on this machine than 10k, too). -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] Amazon.com interview candidate: When C++ is your hammer, everything starts to look like your thumb. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
On Thu, 15 Nov 2007 15:04:07 -0700 Chad Perrin [EMAIL PROTECTED] wrote: On Thu, Nov 15, 2007 at 09:43:16PM +, RW wrote: On Thu, 15 Nov 2007 16:00:55 -0500 Chuck Robey [EMAIL PROTECTED] wrote: I've already deleted the message that kicked me off, but it looked to me that you were talking about the 10,000 ports I was talking about, and that meant you were referring to new installs, not upgrades. Why would anyone want to configure ports they don't want to install? I've been following this discussion without participating, but I have a question: How does that question follow from the preceding, quoted statement? I assumed that he meant all ports, 10,000 is of the same order of magnitude as the total number of ports (27000), but an absurdly high figure for a real system. Actually the total number of ports in the entire tree that support options is only 1447. And out of 821 ports installed on my KDE desktop machine only 140 do. The idea that anyone ever has to configure 10,000 ports is nonsense. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
RW wrote: On Thu, 15 Nov 2007 16:00:55 -0500 Chuck Robey [EMAIL PROTECTED] wrote: I've already deleted the message that kicked me off, but it looked to me that you were talking about the 10,000 ports I was talking about, and that meant you were referring to new installs, not upgrades. Why would anyone want to configure ports they don't want to install? BUT if you were talking only about upgrades, then I kinda think, personally, that you probably should instantiated a new thread, not used this one. Hmm? Is that supposed to irony, because before you hijacked this thread it was about preventing options screens being brought up at build-time, and pausing the build. Your ideas do absolutely nothing to address this issue because, they would only reduce the number of options, not eliminate them - unless you are intending to radically dumb-down the system. As a case in point take a look at the options for www/squid, I don't believe for a moment that your scheme could handle more than a small fraction of them. If people want an easier desktop system, they already have the pc-bsd and DesktopBSD versions of FreeBSD. I need to take exception to that. My claim (and I have the messages in which I made it) is that the setting of options needed these changes: (1) To move the time that they need to be set, from ports compile time to system install time, and (2) To always phrase the questions in a form that non-technical users can field, without extensive research that they are not equipped for, and (3) To find a way to urge both ports-writers and ports users to share the same notion of what the options refer to. I think (I may be wrong, correct me if I am) that you were taking exception, above, to my first point, right? You may correct me on that, but on whether or not it will actually succeed in this is what all this discussion is about. I did not bring this up without bringing the idea past local friends, and defending it there, so I think I can do that. Do i need to requote all of my arguments about that here (and really, by now, boring folks to sleep) or can you look up the older posts? If you've lost them, I've always had problems myself getting really recent posts out of the archives, so write me privately, I will be glad to send them to you. I do believe that it will perfectly accomplish exactly what you claim do absolutely nothing to address this issue, they will 100% move the work from ports build-time to system install-time. This is pretty simple to prove, so I can't follow your assertion, and one of us must have a disconnect here. My points #2 and #3 are more arguable; I believe in them, but I guess an argument could be made against this. There was a second part of my argument, also (a list of regular-exceptions that ports, if they match, would be rejected from), but that part would have somewhat less effect (some, but less obvious). Both parts of my suggestion are things I'm pushing, but at this point, I'm only at the point that I am completely convinced that enough folks do agree with it to justify my writing the Makefile mods. This isn't to say that the work I do will be approved and brought in, you should know the FreeBSD development pattern well enough to realize this, so lets not lose our cool. Save that for the next time it's brought up, ON THE PORTS LIST, not questions. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
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. Tell you what, let's just let this branch of the argument die, until I raise it again after I have the software ready to look at, on the ports list. We should not be bothering the -questions llist with this. 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. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
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 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. I *love* this idea! /me starts cobbling together a list of things that start with 'k' or 'g', preparing for that future date when this is possible. -- CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ] John Kenneth Galbraith: If all else fails, immortality can always be assured through spectacular error. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
On Mon, Nov 12, 2007 at 03:26:00PM +, Ashley Moran wrote: Hi I was just wondering, what is the motivation behind the GUI configuration for some ports? Many people prefer to not have to read every single Makefile in the ports tree just to find out which options are available. It can also be nice having the chosen options automatically saved. Simply put, they drive me up the wall. I've lost count of the number of times I've come back to a big install to find it hanging on a config screen. Possibly I'm missing something. The apache22 port is the latest one to join this crowd, although there is an option to skip the GUI. I'm much happier using WITH_PROXY_MODULES or whatever, and managing everything in pkgtools.conf. What is the best way to pre-configure GUI-configured ports? For example, if I want to script an installation of several ports. 'make config-recursive' to pop up all the config-dialogs before you start building, or 'make BATCH=yes' to skip all the config-dialogs and just use the standard options. Reading the ports(7) manpage can be helpful to find out this kind of things. I've seen this: http://www.freshports.org/misc/dotfile/, is it what I'm after? Doesn't look like it. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
Ashley Moran wrote: Hi I was just wondering, what is the motivation behind the GUI configuration for some ports? Simply put, they drive me up the wall. I've lost count of the number of times I've come back to a big install to find it hanging on a config screen. Possibly I'm missing something. The apache22 port is the latest one to join this crowd, although there is an option to skip the GUI. I'm much happier using WITH_PROXY_MODULES or whatever, and managing everything in pkgtools.conf. What is the best way to pre-configure GUI-configured ports? For example, if I want to script an installation of several ports. I've seen this: http://www.freshports.org/misc/dotfile/, is it what I'm after? I think what you want is the make config-recursive target which should go through the dependencies and do the gui config for them all, (after the first run the gui config saves the configs in /var/db/ports/$portname/options and shouldn't prompt a second time.) For apache22 it looks like setting WITHOUT_APACHE_OPTIONS=YES should disable the menu and let you go back to using pkgtools.conf although I haven't tested it. Its possible that setting BATCH=YES and using pkgtools.conf will work too but my understanding of the BATCH and INTERACTIVE makefile options are a little unclear. I agree though, I often suffer the same problem, coming back after a few hours to a build that should have finished to find its sitting on the first dependency. Vince Thanks for any advice Ashley -- blog @ http://aviewfromafar.net/ linked-in @ http://www.linkedin.com/in/ashleymoran currently @ work ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
Vince wrote: Ashley Moran wrote: Hi I was just wondering, what is the motivation behind the GUI configuration for some ports? Simply put, they drive me up the wall. I've lost count of the number of times I've come back to a big install to find it hanging on a config screen. Possibly I'm missing something. I agree though, I often suffer the same problem, coming back after a few hours to a build that should have finished to find its sitting on the first dependency. Maybe it's been suggested before (in which case I add my vote) but a timeout mechanism would solve this... give the user 10s to provide a keypress else bailout and use the default options. -- Said one park ranger, 'There is considerable overlap between the intelligence of the smartest bears and the dumbest tourists.' Mark D. Foster, CISSP [EMAIL PROTECTED] http://mark.foster.cc/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
On Monday 12 November 2007 17:48, Erik Trulsson wrote: On Mon, Nov 12, 2007 at 03:26:00PM +, Ashley Moran wrote: I've lost count of the number of times I've come back to a big install to find it hanging on a config screen. Possibly I'm missing something. [snip] What is the best way to pre-configure GUI-configured ports? For example, if I want to script an installation of several ports. 'make config-recursive' to pop up all the config-dialogs before you start building[...] I discovered this recently. My big irritation, having decent bandwidth at work and a dialup at home, was fetching ``all'' the required sources for an overnight build on my laptop, finding in the morning that a dialog had popped up during the night and stopped the build, selecting a non-standard option and restarting only to find that it brought in a bunch more dependencies - over my phone line. I now run make config-recursive repeatedly until dialogs stop appearing, then fetch, then build. This recently cut down a build of X.org and KDE from a week (wall time) to less than 24 hours - from memory I ran make config-recursive three or four times on x11/kde3 alone. (Oh, I also got ADSL which helped with the downloads). Jonathan ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
On Mon, 12 Nov 2007 08:14:02 -0800 Mark D. Foster [EMAIL PROTECTED] wrote: Vince wrote: Ashley Moran wrote: Hi I was just wondering, what is the motivation behind the GUI configuration for some ports? Simply put, they drive me up the wall. I've lost count of the number of times I've come back to a big install to find it hanging on a config screen. Possibly I'm missing something. I agree though, I often suffer the same problem, coming back after a few hours to a build that should have finished to find its sitting on the first dependency. Maybe it's been suggested before (in which case I add my vote) but a timeout mechanism would solve this... give the user 10s to provide a keypress else bailout and use the default options. That would involve standing-over the build for hours or days in case you miss a 10-second window - it's just not practical IMO. Setting the menus is pretty easy to script, and you can also set BATCH to take the default options ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
RW wrote: On Mon, 12 Nov 2007 08:14:02 -0800 Mark D. Foster [EMAIL PROTECTED] wrote: Vince wrote: Ashley Moran wrote: Hi I was just wondering, what is the motivation behind the GUI configuration for some ports? Simply put, they drive me up the wall. I've lost count of the number of times I've come back to a big install to find it hanging on a config screen. Possibly I'm missing something. I agree though, I often suffer the same problem, coming back after a few hours to a build that should have finished to find its sitting on the first dependency. Maybe it's been suggested before (in which case I add my vote) but a timeout mechanism would solve this... give the user 10s to provide a keypress else bailout and use the default options. That would involve standing-over the build for hours or days in case you miss a 10-second window - it's just not practical IMO. Setting the menus is pretty easy to script, and you can also set BATCH to take the default options ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] And in fact you can make all these screens appear before actually compiling: make config-recursive (select all wanted options) make install clean (no more questions asked) it is all in the manual: man ports ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
RW wrote: On Mon, 12 Nov 2007 08:14:02 -0800 Mark D. Foster [EMAIL PROTECTED] wrote: Vince wrote: Ashley Moran wrote: Hi I was just wondering, what is the motivation behind the GUI configuration for some ports? Simply put, they drive me up the wall. I've lost count of the number of times I've come back to a big install to find it hanging on a config screen. Possibly I'm missing something. I agree though, I often suffer the same problem, coming back after a few hours to a build that should have finished to find its sitting on the first dependency. Maybe it's been suggested before (in which case I add my vote) but a timeout mechanism would solve this... give the user 10s to provide a keypress else bailout and use the default options. That would involve standing-over the build for hours or days in case you miss a 10-second window - it's just not practical IMO. Setting the menus is pretty easy to script, and you can also set BATCH to take the default options A suggestion I recently made on the ports list would, as a side effect, make a better solution. You see, allowing a default timer does get things built, but then it allows no user input to let users avoid installing software that they either have no ise for, or do not want for other reasons. I have enough input now, so I'm going ahead and coding up the Makefile mods to allow my system, but it looks somewhat like the Gentoo Portage USE flags system. Not identical, and I am only proposing to use their USE flags, not the rest (I very much like using Makefiles as FreeBSD ports does, and wouldn't change that.) If you want to see what it is, go look at recent postings on ports list. It'll probably get changed, as I get something for folks to look at and discuss. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
Chuck Robey wrote: RW wrote: On Mon, 12 Nov 2007 08:14:02 -0800 Mark D. Foster [EMAIL PROTECTED] wrote: Vince wrote: Ashley Moran wrote: Hi I was just wondering, what is the motivation behind the GUI configuration for some ports? Simply put, they drive me up the wall. I've lost count of the number of times I've come back to a big install to find it hanging on a config screen. Possibly I'm missing something. I agree though, I often suffer the same problem, coming back after a few hours to a build that should have finished to find its sitting on the first dependency. Maybe it's been suggested before (in which case I add my vote) but a timeout mechanism would solve this... give the user 10s to provide a keypress else bailout and use the default options. That would involve standing-over the build for hours or days in case you miss a 10-second window - it's just not practical IMO. Setting the menus is pretty easy to script, and you can also set BATCH to take the default options A suggestion I recently made on the ports list would, as a side effect, make a better solution. You see, allowing a default timer does get things built, but then it allows no user input to let users avoid installing software that they either have no ise for, or do not want for other reasons. I have enough input now, so I'm going ahead and coding up the Makefile mods to allow my system, but it looks somewhat like the Gentoo Portage USE flags system. Not identical, and I am only proposing to use their USE flags, not the rest (I very much like using Makefiles as FreeBSD ports does, and wouldn't change that.) If you want to see what it is, go look at recent postings on ports list. It'll probably get changed, as I get something for folks to look at and discuss. USE flags are a pain in the ass (former Gentoo user of 3 years). Introducing that type of complexity into a ports system isn't necessary and does unexpected things at times for end-users when developers change variable names or behavior, which happened quite often with Gentoo. make config-all or something similar to have people fill in their desired config info in all of the ncurses config sections would however be a much better idea I think.. -Garrett ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
Garrett Cooper wrote: Chuck Robey wrote: RW wrote: On Mon, 12 Nov 2007 08:14:02 -0800 Mark D. Foster [EMAIL PROTECTED] wrote: Vince wrote: Ashley Moran wrote: Hi I was just wondering, what is the motivation behind the GUI configuration for some ports? Simply put, they drive me up the wall. I've lost count of the number of times I've come back to a big install to find it hanging on a config screen. Possibly I'm missing something. I agree though, I often suffer the same problem, coming back after a few hours to a build that should have finished to find its sitting on the first dependency. Maybe it's been suggested before (in which case I add my vote) but a timeout mechanism would solve this... give the user 10s to provide a keypress else bailout and use the default options. That would involve standing-over the build for hours or days in case you miss a 10-second window - it's just not practical IMO. Setting the menus is pretty easy to script, and you can also set BATCH to take the default options A suggestion I recently made on the ports list would, as a side effect, make a better solution. You see, allowing a default timer does get things built, but then it allows no user input to let users avoid installing software that they either have no ise for, or do not want for other reasons. I have enough input now, so I'm going ahead and coding up the Makefile mods to allow my system, but it looks somewhat like the Gentoo Portage USE flags system. Not identical, and I am only proposing to use their USE flags, not the rest (I very much like using Makefiles as FreeBSD ports does, and wouldn't change that.) If you want to see what it is, go look at recent postings on ports list. It'll probably get changed, as I get something for folks to look at and discuss. USE flags are a pain in the ass (former Gentoo user of 3 years). Introducing that type of complexity into a ports system isn't necessary and does unexpected things at times for end-users when developers change variable names or behavior, which happened quite often with Gentoo. make config-all or something similar to have people fill in their desired config info in all of the ncurses config sections would however be a much better idea I think.. -Garrett Are you talking about make config-recursive? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
On Mon, 12 Nov 2007 21:04:12 +0200 Manolis Kiagias [EMAIL PROTECTED] wrote: RW wrote: On Mon, 12 Nov 2007 08:14:02 -0800 Setting the menus is pretty easy to script, and you can also set BATCH to take the default options And in fact you can make all these screens appear before actually compiling: make config-recursive (select all wanted options) make install clean (no more questions asked) Yes, but that doesn't work if you are doing a portupgrade -a, you then need to wrap the makes in a simple script, which is what I was referring to. Portmaster has something like this built-in. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
On Mon, 12 Nov 2007 14:18:50 -0500 Chuck Robey [EMAIL PROTECTED] wrote: Setting the menus is pretty easy to script, and you can also set BATCH to take the default options A suggestion I recently made on the ports list would, as a side effect, make a better solution. I don't see why it would. It wouldn't eliminate the config screens - many, if not most, of the existing options couldn't be handled like that. I find the config screens to be a useful way of keeping on top of new functionality, and it's pretty trivial to get them out of the way at the start of an upgrade. All that's really needed is to add this feature (that portmaster already has) to portupgrade. What I've found to be a more awkward problem is ports with interactive deinstall scripts. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
[LoN]Kamikaze wrote: Garrett Cooper wrote: Chuck Robey wrote: RW wrote: On Mon, 12 Nov 2007 08:14:02 -0800 Mark D. Foster [EMAIL PROTECTED] wrote: Vince wrote: Ashley Moran wrote: Hi I was just wondering, what is the motivation behind the GUI configuration for some ports? Simply put, they drive me up the wall. I've lost count of the number of times I've come back to a big install to find it hanging on a config screen. Possibly I'm missing something. I agree though, I often suffer the same problem, coming back after a few hours to a build that should have finished to find its sitting on the first dependency. Maybe it's been suggested before (in which case I add my vote) but a timeout mechanism would solve this... give the user 10s to provide a keypress else bailout and use the default options. That would involve standing-over the build for hours or days in case you miss a 10-second window - it's just not practical IMO. Setting the menus is pretty easy to script, and you can also set BATCH to take the default options A suggestion I recently made on the ports list would, as a side effect, make a better solution. You see, allowing a default timer does get things built, but then it allows no user input to let users avoid installing software that they either have no ise for, or do not want for other reasons. I have enough input now, so I'm going ahead and coding up the Makefile mods to allow my system, but it looks somewhat like the Gentoo Portage USE flags system. Not identical, and I am only proposing to use their USE flags, not the rest (I very much like using Makefiles as FreeBSD ports does, and wouldn't change that.) If you want to see what it is, go look at recent postings on ports list. It'll probably get changed, as I get something for folks to look at and discuss. USE flags are a pain in the ass (former Gentoo user of 3 years). Introducing that type of complexity into a ports system isn't necessary and does unexpected things at times for end-users when developers change variable names or behavior, which happened quite often with Gentoo. make config-all or something similar to have people fill in their desired config info in all of the ncurses config sections would however be a much better idea I think.. -Garrett Are you talking about make config-recursive? Yes =\. Lemme guess.. that's already an option :)? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
Garrett Cooper wrote: If you want to see what it is, go look at recent postings on ports list. It'll probably get changed, as I get something for folks to look at and discuss. USE flags are a pain in the ass (former Gentoo user of 3 years). Introducing that type of complexity into a ports system isn't necessary and does unexpected things at times for end-users when developers change variable names or behavior, which happened quite often with Gentoo. make config-all or something similar to have people fill in their desired config info in all of the ncurses config sections would however be a much better idea I think.. -Garrett Good point. My main drive is to stop asking users to OK dependencies to specific pieces of software (which most users haven't the least idea about), and also to move the gathering of data out of ports-compile-time and into system-install-time (perhaps with an update feature as hardware changes). The way that Gentoo did it, if followed slavishly, yes, I agree it would just leaad to more confusion. I got the feeling that you are asking for a ncurses sort of app, that would gather data, and tjhen be used to control the setting of dependencies? Is that right? I would think that the linkage between the program amd the ports could be a list like the Gentoo USE lists, but without any direct interface to it, so building and maintaining the list becomes the responsibility of the program and not clueless users. That more what you see? I could live with that quiurte easily. But, such a system is more than could be written directly either in Make or using sh ... I mean, you _could_ use sh, but the software would be too complicated to maintain. Could I use some tool? I would not exactly love doing it in C, but I guess I could do that (I'd rather use something like Python, but it's not available in the base, and I think I would want this available at system install time. Please, comment more, I think I like the way you're driving this, so let me see if I have really gotten your idea. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
Garrett Cooper wrote: [LoN]Kamikaze wrote: Garrett Cooper wrote: USE flags are a pain in the ass (former Gentoo user of 3 years). Introducing that type of complexity into a ports system isn't necessary and does unexpected things at times for end-users when developers change variable names or behavior, which happened quite often with Gentoo. make config-all or something similar to have people fill in their desired config info in all of the ncurses config sections would however be a much better idea I think.. -Garrett Are you talking about make config-recursive? Yes =\. Lemme guess.. that's already an option :)? 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. These are both bad options. Also, asking users to pick if a particular piece of software, one that they most liely have never heard of, can be used, is not a particularly good way to get the info either. Gentoo's idea of a USE list has some good points, and some bad points. The worst part is that keeping that USE list corect is too damn difficult. BUT if we made that list private, so be manipulated solely by a more intelligent program, one that could ask better quetions, and let that maintain the list, that would stop the ports-build-time interruptions, and also make things much much easier for users, even technical users, to administer. Just don't let folks need to maintain that list themselves. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
On November 12, 2007 at 03:14PM RW wrote: [ ... ] Yes, but that doesn't work if you are doing a portupgrade -a, you then need to wrap the makes in a simple script, which is what I was referring to. Portmaster has something like this built-in. From man PORTUPGRADE(1): -- batchRun an upgrading process in a batch mode (with BATCH=yes) -- Gerard It has always been the prerogative of children and half-wits to point out that the emperor has no clothes. But the half-wit remains a half-wit, and the emperor remains an emperor. Neil Gaiman ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
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. That's not correct, you can run make config-conditional or make config-recursive anytime you like. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
RW schrieb: 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. That's not correct, you can run make config-conditional or make config-recursive anytime you like. But not on a portupgrade... I don't want to run config-recursive on the whole ports tree though ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
On Mon, 12 Nov 2007 16:25:47 -0500 Gerard [EMAIL PROTECTED] wrote: On November 12, 2007 at 03:14PM RW wrote: [ ... ] Yes, but that doesn't work if you are doing a portupgrade -a, you then need to wrap the makes in a simple script, which is what I was referring to. Portmaster has something like this built-in. From man PORTUPGRADE(1): -- batchRun an upgrading process in a batch mode (with BATCH=yes) Yes, I already wrote: .. and you can also set BATCH to take the default options but BATCH is a kludge if you actually want the options screens, but don't want builds interrupted. Much better to do the make configs separately in one go. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
On Mon, 12 Nov 2007 22:54:33 +0100
Tino Engel [EMAIL PROTECTED] wrote:
RW schrieb:
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.
That's not correct, you can run make config-conditional or make
config-recursive anytime you like.
But not on a portupgrade... I don't want to run config-recursive on
the whole ports tree though
It's not hard to script it though, something like the following would do
#!/bin/sh
for p in `pkg_version -ol'' |awk '{ print $1 }'`; do
cd /usr/ports/${p} make config-recursive
done
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
Gerard wrote: On November 12, 2007 at 03:14PM RW wrote: [ ... ] Yes, but that doesn't work if you are doing a portupgrade -a, you then need to wrap the makes in a simple script, which is what I was referring to. Portmaster has something like this built-in. From man PORTUPGRADE(1): and my (twofold) point is that (1) this removes all real choices from the user, and (2) there is a perfectly good method that allows one to keep their own options, and still get all the good points of batch processing. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
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]
Re: Ports with GUI configs
RW wrote:
On Mon, 12 Nov 2007 22:54:33 +0100
Tino Engel [EMAIL PROTECTED] wrote:
RW schrieb:
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.
That's not correct, you can run make config-conditional or make
config-recursive anytime you like.
But not on a portupgrade... I don't want to run config-recursive on
the whole ports tree though
It's not hard to script it though, something like the following would do
#!/bin/sh
for p in `pkg_version -ol'' |awk '{ print $1 }'`; do
cd /usr/ports/${p} make config-recursive
done
I can't believe you actually suggested this. First thing, it would take
you HOURS to complete, and you better not make even one mistake, 'cause
you couldn't even go back far enough to figure out what the name was of
the port you muffed. Beyond that, since most ports ask questions formed
with the name of the target dependency, aznd not asking things like do
you want such-and-such capability, so you have to be conversant with
the names and capabilities of nearly 10,000 ports, to be able to do that
job.
Were you really seriously suggesting this. It's so unworkable, its
laughable.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
Not to mention, as a novice, I've discovered that for 20-60% of all ports, messing with the defaults makes the port fail to build Steve On Nov 12, 2007 8:26 AM, Ashley Moran [EMAIL PROTECTED] wrote: Hi I was just wondering, what is the motivation behind the GUI configuration for some ports? Simply put, they drive me up the wall. I've lost count of the number of times I've come back to a big install to find it hanging on a config screen. Possibly I'm missing something. The apache22 port is the latest one to join this crowd, although there is an option to skip the GUI. I'm much happier using WITH_PROXY_MODULES or whatever, and managing everything in pkgtools.conf. What is the best way to pre-configure GUI-configured ports? For example, if I want to script an installation of several ports. I've seen this: http://www.freshports.org/misc/dotfile/, is it what I'm after? Thanks for any advice Ashley -- blog @ http://aviewfromafar.net/ linked-in @ http://www.linkedin.com/in/ashleymoran currently @ work ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] -- Steve Franks, KE7BTE Staff Engineer La Palma Devices, LLC http://www.lapalmadevices.com (520) 312-0089 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
On Mon, 12 Nov 2007 20:37:11 -0500
Chuck Robey [EMAIL PROTECTED] wrote:
RW wrote:
On Mon, 12 Nov 2007 22:54:33 +0100
Tino Engel [EMAIL PROTECTED] wrote:
It's not hard to script it though, something like the following
would do
#!/bin/sh
for p in `pkg_version -ol'' |awk '{ print $1 }'`; do
cd /usr/ports/${p} make config-recursive
done
I can't believe you actually suggested this.
First thing, it would take you HOURS to complete,
Typically you can do make config-recursive's about 10-30 times per
minute on average - most installed ports have few dependencies. It's
also only running over out-of-date ports, so it only takes minutes,
even for major upgrades.
I now use config-conditional which is faster, and works well enough in
practice not to warrant the extra time.
and you better not make even one mistake,
'cause you couldn't even go back far enough to figure out what the
name was of the port you muffed.
Both config-recursive and config-conditional use cached options where
availible. Options are pretty stable, so even in a major upgrade I only
see a few screens, and 90% of the time they are all trivial.
Beyond that, since most ports ask
questions formed with the name of the target dependency, aznd not
asking things like do you want such-and-such capability, so you
have to be conversant with the names and capabilities of nearly
10,000 ports, to be able to do that job.
I find the one-line descriptions to be pretty good, and my experience
has been that if I don't understand an option, I don't need to change it
from the default.
For the most part, I find that the more inscrutable options are internal
to the port, and have nothing to do with dependencies or any global
setting, for example the patch options in dns/djbdns.
Were you really seriously suggesting this. It's so unworkable, its
laughable.
I've been doing it this way for a long time, it works fine.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
Chuck Robey wrote: Garrett Cooper wrote: [LoN]Kamikaze wrote: Garrett Cooper wrote: USE flags are a pain in the ass (former Gentoo user of 3 years). Introducing that type of complexity into a ports system isn't necessary and does unexpected things at times for end-users when developers change variable names or behavior, which happened quite often with Gentoo. make config-all or something similar to have people fill in their desired config info in all of the ncurses config sections would however be a much better idea I think.. -Garrett Are you talking about make config-recursive? Yes =\. Lemme guess.. that's already an option :)? 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. These are both bad options. No, you got it wrong. You run 'make config-recursive' and get all the configure screens at once. Afterwards you can just run 'make install clean' and go away. Read the ports(7) manpage. If you're using sysutils/bsdadminscripts you can run 'portconfig-recursive -a' before a 'portupgrade -a' in order to avoid having someone sit in front of the machine during the portupgrade. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
Steve Franks wrote: Not to mention, as a novice, I've discovered that for 20-60% of all ports, messing with the defaults makes the port fail to build Steve This sounds rather unlikely if you use the provided WITH_* flags. In case you do something else with ports - well it's not meant to be done and thus your problem if it doesn't work. Messing with ports in an unintended way just screws up the plists, which results in an inconsistent package database. PS: Please don't top-post. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Ports with GUI configs
Chuck Robey wrote:
RW wrote:
On Mon, 12 Nov 2007 22:54:33 +0100
Tino Engel [EMAIL PROTECTED] wrote:
RW schrieb:
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.
That's not correct, you can run make config-conditional or make
config-recursive anytime you like.
But not on a portupgrade... I don't want to run config-recursive on
the whole ports tree though
It's not hard to script it though, something like the following would do
#!/bin/sh
for p in `pkg_version -ol'' |awk '{ print $1 }'`; do
cd /usr/ports/${p} make config-recursive done
I can't believe you actually suggested this. First thing, it would take
you HOURS to complete, and you better not make even one mistake, 'cause
you couldn't even go back far enough to figure out what the name was of
the port you muffed. Beyond that, since most ports ask questions formed
with the name of the target dependency, aznd not asking things like do
you want such-and-such capability, so you have to be conversant with
the names and capabilities of nearly 10,000 ports, to be able to do that
job.
It will only operate on 1 ports if you have 1 ports installed and a
majority of them is outdated.
I'm of the impression that you don't really know what the commands do you're
shown here and come to ridiculous conclusions because of this.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
