Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Mar 2012 10:51:14 -0600
From:      Andrew Gould <>
To:        David Jackson <>
Subject:   Re: Still having trouble with package upgrades
Message-ID:  <>
In-Reply-To: <>
References:  <>

Next in thread | Previous in thread | Raw E-Mail | Index | Archive | Help
On Wed, Mar 7, 2012 at 10:28 AM, David Jackson <> wrot=
> I still have yet to find a resolution to the problems I have had with
> binary packages and upgrades on FreeBSD. Binary upgrading is broken with
> every tool I have tried.
> There is no real reason why FreeBSD should not provide a facility for use=
> to be able to binary upgrade to the most recent version of all packages
> with a simple upgrade command.
> One faulty argument I heard was that it is often not a good idea to upgra=
> to new software release. The whole purpose of having a release cycle for
> programs is to provide stable, tested releases for the public to install
> that will will work properly, and improve upon and fix problems with olde=
> releases. This is why mainline release are differentiated from betas and
> the CVS downloads which are experimental. So you really do want the most
> recent release, especially for corrections to any security problem. Makin=
> upgrades more difficult actually makes the system more insecure by exposi=
> people for a long time to security problems that were fixed in software b=
> making it difficult for people to upgrade.
> As for the security issues of downloading binary packages. The fact is
> source packages are not safer than binary packages, more on that in a bit=
> I am astonished that people here would not realise the obvious, having sa=
> binary installs is do-able from mirror sites, just have the package
> management software download MD5s from many mirror sites, compare them an=
> test the downloaded package, is they are off, then the package will not b=
> installed the user will be prompted to allow a notification of the proble=
> to be sent to the FreeBSD administrators. The fact is, binary releases ar=
> no more dangerous than source releases, someone could just as easily inse=
> bad code in a source code package on a mirror, you need automated MD5
> checking anyway, for both binary or source upgrades. So the idea that
> source upgrades are safer is false, just dead wrong.
> As for compile options, the solution is simple, compile in all feature
> options and the most commonly used settings into the binary packages, for
> the standard i386 CPU. If people want customisations then they can build
> the software for themselves.
> A good software philosophy is to allow software to work out of the box wi=
> as little configuration as possible, but allow everything to be configure=
> by the user if they want, by shipping software with reasonable defaults
> which can be overridden by the user. Make simple things easy and
> complicated things doable. In GUI, by default, complexity can be hidden
> from users, but if people want fine grain control, they should be free to
> use advanced screens of the GUI to get complex, fine grained control. In
> GUI design, more commonly used settings can be provided more upfront whil=
> advanced features for use by experts can be placed deeper in advanced or
> expert screens oft the GUI. Everything should be able to be configured or
> accomplished by both GUI and CLI and API.
> A good user friendly model for a useable OS is to allow for binary packag=
> of the entire system to be upgraded with a single upgrade command. It
> should work out of the box without hassle. Keeping software up to date to
> recent releases is good practice, remember what I said about the purpose =
> software releases. make it easy.
> why dont the freebsd administrators just have a build machine that
> automatically compiles the software and makes them available as the ports
> are updated.
> The user should be able to =A0keep their system up to date without doing =
> system wide all at once OS-release upgrades at all. There is no reason wh=
> kernel and userland programs have to be upgraded at the same time.
> Especially considering its a good design practice for kernel to provide
> backward compatability. Instead the system would be piecemeal updated ove=
> time, including the kernel, in a piecemeal fashion. The need for system
> wide OS distribution version numbers like FreeBSD 9.0 is becoming obsolet=
> Versions are still very valuable for the kernel, but for collections of t=
> entire system software, it has become much less relevant. =A0This was fro=
m an
> age when people would receive a Tape or CD in the mail and update
> everything all at once, now software can be upgraded in a piecemeal way
> over time with automatic updates. The CD-based upgrade and all at once
> system wide upgrades actually for reasons are inferior, in that it meant
> often months would go by before a software program was updated, delying t=
> application of vital security fixes. Before the age of the internet and t=
> hacker, that may have been acceptable. Its not anymore. With Firefox and
> Flash for instance, security fixes are made sometimes weekly, with an
> system wide at once upgrade model, it could be a very long time between
> upgrades of such software between releases of the OS software distributio=
> CD. The idea of waiting on a FreeBSD kernel release to upgrade firefox is
> absurd, and the idea that firefox must be upgraded during a kernel upgrad=
> is also absurd. The piecemeal model is much more convenient for users,
> providing more up to date packages and no OS release upgrade hassle.
> There really should be little reason for release upgrades anymore these
> days, when the different parts of the system can be upgraded independantl=
> through a binary package management tool, including kernel and user
> programs.
> When a new kernel is released, there is no reason to reinstall all of the
> packages on the system at the same time. Since the kernel and userland
> packages have different development cycles, there is no reason why there
> has to be synchronization of the upgrading.
> Some here suggested PC-BSD, it was no better at all than FreeBSD, In fact
> in its documentation it demanded a complete system reinstall just to
> upgrade to a new kernel version. An OS that requires a user to reinstall
> everything just to upgrade the kernel is not user friendly. It creates mo=
> trouble and difficulty for users and ironically makes the system more use=
> unfriendly, and makes these users suffer due to the design faults of the
> system, a user having to upgrade userland packages for a kernel upgrade i=
> a symptom of serious design faults and deficiencies. These two parts shou=
> be able to be upgraded independently and a good system assures backwards
> compatability support so older packages can run on a newer kernel.
> For now I have totally given up on FreeBSD, all I had with FreeBSD were
> problems, big problems. The lack of smooth binary upgrades, and the poor
> virtual box support made it very difficult to use.
> _______________________________________________

Many of your issues are non-issues, as your suggestions were
implemented in some form long ago.  For example, updated applications
are compiled and available online.  You can use "pkg_add -r" to
install the newest binary package that is available, or you can update
your an installed application by updating the ports and using
portupgrade, which has options to control whether you compile updates
from source or install binary packages.

FreeBSD is a very flexible and powerful operating system.  That power
and flexibility, however, requires the user to take the time to learn
the operating system and its options.  This may mean that FreeBSD is
not for everyone.  That's okay.  I don't know of any operating system
that meets everyone's needs.  I don't know of one operating system
that meets all of my needs.  That's okay too.  Every tool has its best


Want to link to this message? Use this URL: <>