branches, updates, buildworld

Todor Genov todor.genov at
Wed Sep 10 19:14:39 UTC 2008

> OK. It brings another question. For example Postgres is not a part of
> the base system. Will it break if i make:
> ##
> pkg_add -r postgresql83-server.tbz
> cvsup /usr/share/examples/cvsup/standard-supfile
> make buildworld
> make buildkernel
> make installkernel
> reboot (in single mode)
> mergemaster -p
> make installworld
> mergemaster
> reboot
> ##

 The pre-compiled binary depends on certain system calls and library
APIs to function. As long as those don't change the binary will continue
to work. It's highly unlikely to have any such changes occur between
RELEASE-p? versions unless they are extremely critical updates. In fact
in most cases you will probably find that your binary will continue to
work between RELEASE versions (7.0, 7.1 etc).

 We trust the developers won't go and and change libc without giving us
a heads-up, but you should still read the changelog before upgrading the
base system and know what to expect.

> ...And what should I do if Postgres (or any other arbitrary binary
> package) breaks afterwards? How should I keep the binary packages
> up-todate? Actually I intend to
> compile Postgres from the ports after success in re-building and
> installing the base system, but the question still remains.

 You can always reinstall it from ports which will compile and link
software according to your existing environment.

 To manage already installed packages you can use portaudit and
portupgrade both of which can be found in the ports tree as well as the
pkg_* tools included in the base system.

>>  > 4) Will "make buildworld" fail with a make.conf like this:
>> Seems OK on first inspection. Guess you won't know till you run the
>>  buildworld :)
> I was kind of hoping not to figure out the optimal combination of gcc
> flags by following the "generate and test" method on Pentium-2. :)

 Take a look at /usr/share/examples/etc/make.conf and use that as your
starting point if you haven't already done so. Most of your options seem
to be in line with the recommended defaults except maybe "-combined" - I
have no idea how it will affect the build. I would use -O2 rather than
-O3 as there's a good chance you'll end up with broken code rather than
any noticeable performance gains.

> Last but not least: Thanks for the fast and detailed response. I
> appreciate it very much.

Glad I could be of help.


Todor Genov
Systems Operations

Verizon Business South Africa (Pty) Ltd

Tel: +27 11 235 6500
Fax: 086 692 0543

More information about the freebsd-questions mailing list