gemeral questions (noobish)

[Giorgos Keramidas]

On Sat, 2 Aug 2008 18:32:53 +0200, mcassar <marshc187 at gmail.com> wrote:
> damn, thanks - I had mistaken stable to be what is release; i had come
> across the difference at some point but didn't realise when i tried
> cvsup (which i also mistook to be more recent than csup).

First of all, a hearty "welcome" :)

You've only been reading about FreeBSD for a month, but you already
managed to install fairly big packages, like KDE and XFCE, learn about
csup, supfiles, the ports, and a lot of other stuff.  Congratulations on
the progress, and we hope you will enjoy FreeBSD as much as many of us
also do.

> 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).

One of the important details about keeping up to date with FreeBSD is
that you usually have *two* options for almost everything:

    - Update from the source

    - Update from 'binaries'

(1) The source side of things

The full source to the base system and the full source of the Ports,
including change history (like who made a change, when, and why), is
available online.  This is an important part of the whole FreeBSD
"culture", and it works in several nice ways: (a) You can go "back" when
a change is made but you don't like it, (b) you can see who made a
particular change and why, and this works a lot of time both as a
tracking tool and, almost as importantly, (d) as educational.

So if you want to learn more about how a fairly large body of source
code is maintained for several different architectures by a large,
distributed team of enthusiastic volunteers, the full history of FreeBSD
is available for browsing.

The source for FreeBSD is available through a variety of means.  Tools
like CVSup, csup, and Subversion can be used to pull copies of the
source with or without its full history.  The same tools (CVSup and
csup) can be used to pull and periodically re-synchronize copies of the
source for: the base system, the Ports collection, our documentation, or
our web site.

If you plan to build several versions of the source tree, from one of
the various "branches" of development, it is nice to be able to switch
from one version to the other without heavy utilization of the network.
In this case, CVSup is a great way of pulling full "mirrors" of the CVS
repositories.  But this needs a fair amount of disk space (slightly more
than 2 GB the last time I checked for a full repository mirror of the
src/, doc/, www/ and ports/ repositories).

(2) The 'binary' side of things

On the other hand, if you don't really want to dig that far into the
"source" part of things, and you just want to get some work done, you
can use a second collection of "update tools" like:

    * freebsd-update

      For updating the binaries of the base system.

    * portsnap

      For downloading snapshots of the /usr/ports tree

    * portupgrade with the -PP option

      For updating the installed third-party packages, using only the
      prebuilt binary packages of the FreeBSD port-builders team.

The choice between checking out the source from CVS and using the
prebuilt code whenever possible is something only *you* are qualified to
make for yourself.  Disk space constraints, limits to the time you can
put into keeping the system update, and the level of "bleeding edge" you
want to keep up with may influence your final decision and push towards
one or the other option.

The nice thing about it all is that you *do* have a choice :-)

> 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.

The short answer to "Should I bother?" is "Sure, please do.  Before you
start 'hacking' at ports, however, we should make it clear that a lot of
the existing problems are already fixed and it takes a certain amount of
dedication, time and effort to fix the remaining bits.".

The longer answer, which is slightly more interesting IMHO, is...

The number of broken, completely bogus or just 'unportable' assumptions
people make when they write software is mind-numbing.  It is often
utterly incomprehensible and absolutely stunning how many or how serious
assumptions some third-party tools make.

All this leads to a lot of the warnings you mentioned above.

The FreeBSD port maintainers commonly make an effort to fix these
problems as part of the "porting effort".  This is why many of the ports
have local, FreeBSD-specific patches.

If you look in a typical port, there is a "files/" subdirectory which
includes FreeBSD patches.  Some of these patches are portability fixes.
Others are merely interesting and useful enhancements that take
advantage of special FreeBSD-only features.  There are also patches that
are just useful build-time options that serve only to integrate the
specific third-party package into the FreeBSD Ports collection in a
slightly better way.  There are even more reasons why the Ports team
chooses to patch a third-party package, and I'm probably forgetting even
some of the important ones.

This is just a long-winded way of saying that the Ports Collection
already fixes a *lot* of things that third-party packages do or need.
If you see something that is broken, and you have the experience to fix
it for FreeBSD Ports, then by all means please help the porters.  They
need all the help they can get :)

If, on the other hand, you feel that something is odd, strange, not good
enough, or outright broken, but you don't want to "mess with the
source", you can still help by reporting what you find.  Learn about the
bug reporting tools, learn to use the "send-pr" utility, the FreeBSD web
interface for checking out and searching our bugs database, the mailing
lists that people hang out in, the various teams that work with a
collection of ports, or how to find, contact and discuss things with the
maintainer(s) of particular ports.

FreeBSD is a nice system, but we heavily depend on the contributions of
our users to improve, extend and maintain it.  Quoting from the "About"
pages of our web site, here's what you should really always keep in mind
when you find out about something that can be improved:

    It is easy to contribute to FreeBSD. All you need to do is find a
    part of FreeBSD which you think could be improved and make those
    changes (carefully and cleanly) and submit that back to the Project
    by means of send-pr or a committer, if you know one.  This could be
    anything from documentation to artwork to source code.  See the
    `Contributing to FreeBSD'[1] article for more information.

    [1] http://www.FreeBSD.org/doc/en_US.ISO8859-1/articles/contributing/index.html

That's the core values of the "FreeBSD community" right there.  In a
short, nicely written paragraph.  This is IMHO the best angle of attack
for any FreeBSD problem you have.  "If you can help us fix and improve
it all, then please do" :-)

Have fun with your FreeBSD installations,
Giorgos