gemeral questions (noobish)

Michael Powell nightrecon at
Sat Aug 2 17:36:53 UTC 2008

mcassar wrote:
> I only tried csup on ports once and wasn't too sure i should since the
> handbook or somewhere mentioned the ports tree should be empty the first
> time you run it; and got the impression you should only use either or
> (csup vs portsnap).

I can only speak to cvsup or csup (which I use) but I'd like to point out a
very common mistake wrt either. It is a good idea to have two different sup
files, as they will need to download different collections of material. For
example this:

*default release=cvs tag=RELENG_7_0

combination will pull down the system sources for the security updates to
RELEASE. Read in the Handbook about the tags and collections.

I keep a separate sup file for keeping the ports tree updated and the
difference is here:

*default release=cvs tag=.

Please notice that if you use the "tag=." with "src-all" you will pull down
HEAD, which is the "bleeding edge" of development and not what a beginner
should be using. But when used with the ports "collection" you will get an
up to date ports tree.
> anyhow i think that only my nvidia driver instructions mentioned it relies
> on what i think are system sources (kernel related - if i'm not mistaken)
> - but i haven't touched that yet.

Generally speaking before building something like the nvidia drivers using
the ports system the best first step is to refresh the ports tree. With all
dependencies tracked and updated you'll likely have more success. Notice,
for instance, that the nvidia driver depends on having what we call
the "linuxulator" installed. It'll do this for you but you may have to
enter a line in your /boot/loader.conf to ensure the linux.ko kernel module
gets loaded every time at boot. You will usually see some more instructions
at the end if you need to do anything special. Also, be aware that the
nvidia driver is only currently working with i386, _not_ amd64.

Even if only using packages you should _still_ update the ports tree, as the
package system relies on it for dependency tracking as well.
> I hate to bother any further but have one thing to clarify about building
> attempts - when building anything, if that's ok. I only have a basic
> understanding of C so far, and can't really tell how critical warnings are
> - such as undefined this and that, defined but not used...etc, when
> building a
> port.  should i stop those and see how i should fix them or let them
> proceed as long as they're not errors? I can live with my current system
> for now, but have a few things i need to update eventually.

When you use ports and compile stuff, you may see all manners of warnings,
errors, and sundry garbage spewing forth from the compiler. Most of this,
most of the time, is benign and not something to get overly concerned about
as it is fairly normal. The exception is if the build errors out and
completely quits, and there is an error sequence that will indicate
whereabouts it bombed. Sometimes ports do get broken and need fixing, but
most ports have a person who maintains them. If/when many people see the
same error someone usually notifies the port maintainer and he/she then
looks into fixing it.

But generally speaking, if the build completes and runs without segfaulting
just ignore what you may have seen scrolling by while building. Most of the
time it's just "noise".  :-)


More information about the freebsd-questions mailing list