Date: Fri, 12 Mar 1999 18:01:56 +0100 From: Roelof Osinga <roelof@eboa.com> To: John Polstra <jdp@polstra.com> Cc: questions@FreeBSD.ORG Subject: Re: CVSup: a newbie's tale. Message-ID: <36E94884.978847CB@eboa.com> References: <XFMail.990311214143.jdp@polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
John Polstra wrote: > > I'm sorry, but I disagree with that proposal. In Unix it has always > been understood that "the name" of a file means "whatever it takes to > reference it from your current working directory." (For that matter, > the same assumption holds even under DOS or Windows.) That's assumed > in all of the manual pages -- see cat(1) or ls(1), for example. I love it when they fight back ;). Granted in so far we're talking about just any ol' file. But we're not. At this stage (in the manual as well as the process) we are configuring. As such we're dealing with configuration files. You know... the things Unix traditionally stores in /etc <g>. The archetypical /etc/rc springs to mind. Heck, even DOS and its GUI Windows expect their configutation files to be at well-known locations like the root of the C disk or in the Windows installation directory. In that it is indeed just like Unix, for does not even X look for its configuration files in well-known locations? So in a way the very term configuration implies well-known locations. As soon as one reads configuration files one thinks, oh, I dunno, /etc or home directories or, if you're modern minded /usr/local/etc/ or /usr/local/cvsup/etc or something, maybe even /usr/local/etc/cvsup for who needs standards anyway <g>. But some directory that is well-know to the daemon one is installing. Take a daemon, any daemon, sendmail, apache, whatever. Sendmail looks for local.cf in /etc and apache for httpd.conf in /usr/local/apache. Sometimes one can start a daemon so that it looks in another, thus not standard, location. But that is an option. If Samba does it like this, why shouldn't CVSup? But on the bright side. I do agree with you. One should be able to deviate from the norm by providing a filename. In which case, i.e. the case wherein it is (made) clear that one is deviating, one could talk about 'filename' in the safe knowledge that it is clear what is meant. > It really really will, if it was built and installed right. If > you're having problems with it, I'd recommend that you install > the "cvsup-bin" port from the "net" category. That's the least > trouble-prone one. Famous last words <g>. I'm not having problems with it. But, suppose you're right and somehow it wasn't built or installed right. Then clearly I'm having problems with at least the documentation <g>. For I can't see how I could fail to do 'make install' right. Also I do remember noticing: "To build this port without X11 (and without the GUI), define NO_X11". But no dialog. I just listed the env. vars in bash and it does not have NO_X11 defined. > > Last, but not least, we get to the topic of ports. Now imagine if you > > would your average nervous newbie. Having never done this before one > > reads the handbook with bated breath in the hope of gaining, if not > > wisdom, at least heightened awareness of the pitfalls involved. Like, > > oh, say, will it mean downloading and thus storing all sources. I.e. > > of every available port? > > > > As it turned out, it doesn't. Which is nice since I only had a mere GB > > left on the /usr device. Perhaps it would be an idea to inform the > > audience of the scope of what one's about to attempt? > > Well ... maybe. The tutorial is really about CVSup, not about the > details of the ports collection or any of the other files that you can > fetch. Information about those things is elsewhere. It's not the details of the port collection one wants to know, merely what CVSup is about to do. I could care less about the details of some port, but I would like to know whether or not it gets fetched. And if I get to have a say in it. And if so what say and how to say it. You might know what it does, but the one that reads the manual does not. Which is of course why such a one reads the manual in the first place :). > It's important to realize that CVSup and make world really aren't > intended for new users. Either one can get you into trouble unless > you have a certain level of familiarity with Unix. Maybe that's > something I should make more clear in the tutorial. I think you > should use FreeBSD for awhile and become more familiar with it before > you start trying make worlds in particular. You'll feel a lot less > nervous about it once you are more comfortable with the system. Wouldn't do you any good. I needed to get CVSup up and running because one port was updated since RELEASE-3.1. Sh*t happens and when it does one gets the advice to go the CVSup way. Besides, I've been using Unix since '86 and can still come up with these questions. So how many years prior Unix experience were you thinking about? ;) Also it is not that complicated. As far as I can see there are but a few minor details that should be made more clear in the manual. In order to prevent some unnecessary questions. > > PS this is not intended as negative criticism ... > > No problem -- it didn't seem negative at all to me. Hm. Skipped sensitivity training again, I see <g>. Roelof -- Home is where the (@) http://eboa.com/ is. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?36E94884.978847CB>