Upgrading FreeBSD 8.3 amd64

Polytropon freebsd at edvax.de
Thu Dec 20 04:29:15 UTC 2012


On Thu, 20 Dec 2012 05:13:39 +0100, Ralf Mardorf wrote:
> Thank you Erich :)
> 
> ok, so "FreeBSD release" is the version of the kernel and not a
> labelling for the collection of all the software.

No. The version specification refers to the version of the
kernel _and_ the operating system (which form a unit maintained
by the FreeBSD team). Those typically have to be in sync.
Depending on what branch you follow, this can be:

a) a static release number, e. g. 8.2-RELEASE

b) a release, enriched by security updates, e. g. 8.2-RELEASE-p2

c) a stable version, e. g. 8-STABLE of a specific date
   (this is "work in progress" that has been considered working)

d) a development version, e. g. 10-CURRENT
   (this may or _may not_ even compile, it's experimental)

Depending on what branch you follow, updating techniques may
differ: freebsd-update (the binary way) can be used for a) and
b); for c) and d) you update from source.



> For Linux major distros there usually is a labelling for the collection
> of the software, independent of the kernel version.

Linux doesn't know the differentiation between "the operating
system" (consisting of the OS kernel and the OS programs, the
"world" in FreeBSD terminology) and "everything else" (third
party contributed applications, in FreeBSD provided by the
ports collection).




> On Linux I usually install binaries for the base system and desktop
> environment, but for important software, in my case it's audio,
> compiling from source is very important.

The ports collection allows both binary installation and by source.
There are tools that help managing them.

Note that unlike Linux, FreeBSD draws a line between "the OS"
and "installed applications" - you need to install and update
them separately. This is a big benefit as a failed program
installation can never harm your OS.



> The author of the snd_hdspe driver for FreeBSD seems to need testers. It
> seems to be that nobody ever tested if ADAT is working and I'll test it.
> OTOH I suspect bug fixes for the driver have to be added by recompiling
> the kernel or at least the driver for the kernel, so I still could use
> binaries for the applications.

Of course. The separation I've mentioned explicitely allows this
method to function. What you need to do is to update your sources
in /usr/src and then recompile the kernel and, if required, the
world, as explained in /usr/src/Makefile's comment header.



> Since audio on FreeBSD seems to be a niche, I wonder if it's more
> promising, to go the source or to go the binary rout.

I'd say: Use the source Luke. :-)

Experimental changes and "bleeding edge updates" are typically a
domain of source installations. With svn you can track smallest
changes very quickly, apply them to your system and have a test
run. Doesn't work? Undo the change, or wait for a new version.



> I suspect if it's impossible or at least less good to mix binaries and
> from source build software for FreeBSD, I should chose to build from
> source.

Basically there is no problem. One thing you have to pay attention
to is dependency versions, but that's what port management tools
like portmaster can do for you.




-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...


More information about the freebsd-questions mailing list