View Full Version : Expect issues upgrading?
February 4th, 2009, 16:48
I'm using Debian testing (linux) for over 1 year. This Debian branch has updates to its packages basically everyday and I install them everyday. I never had issues. I basically only use GNOME, Firefox and OpenOffice.
I would like to change to FreeBSD 7.1 but I've been reading posts that there are issues upgrading. If I change to FreeBSD, will I expect problems whenever the time comes to upgrade? (I only intend to use port-binary-packages rather than port-source-packages).
February 4th, 2009, 21:35
what is your hardware?
firefox3 takes 2 1/2 hours on a 2.0 p4 here.
I do not use openoffice. the "freebsd-questions list" has q/a on its installs often.
portupgrade -P firefox3 would (probably) upgrade/install it by package
if I did not have the time.
the thing is each port is unique, some are VERY easy, some difficult,
but there are many (easy) tricks to each aspect of upgrading. If you switch
to BSD you will learn a lot, but not at once. (such tricks are learned
as you go along and read guides, threads, posts, etc).
Gnome is a problem here. I have a list of how-to-upgrade (this-then-that)
since I always upgrade manually. But as I do not use gnome proper I can
do it over several days. Others do it with a single command I think
This is just an overview, more than a definitive answer.
February 5th, 2009, 00:12
Two of the last Xorg updates were a little bit problematic, but the other stuff works/upgrades ok. However, problems are rather rare...
February 5th, 2009, 12:11
If I change to FreeBSD, will I expect problems whenever the time comes to upgrade? (I only intend to use port-binary-packages rather than port-source-packages).
FWIW, my experiences so far (also coming from linux)...
If you're an update-a-holic, you'll quickly end up installing from source. Packages can take a while to become available. I've swapped between manual, portupgrade and portmaster. I'm currently with portmaster as it seems to have more robust dependency options if (or rather when) you hit a difficult port. Downside is that portmaster is source only.
Things do break (as Hydra points out, the last xorg update was a pig). But things also break on Linux - and it's usually for the same reasons (2nd-level dependencies, config variations etc). The big difference is Linux has a much larger user/maintainer pool with which to detect and resolve issues. Check out the FreeBSD mailing lists and you'll see single individuals heroically managing to put out fires, all while trying to hold down a real-life. A smaller user pool also means genuine issues might go unnoticed longer, or be kept lower priority until others confirm (I have hw issues that were reported years ago, which have patches available, that still have not been integrated - probably because there isn't enough 'support' for them).
On the plus side, I had a perfect experience upgrading from 7.0 to 7.1.
If you need your machine for anything critical, then I'd advise keeping a Debian partition available. At least until you've worked through enough FreeBSD 'quirks' to know how to resolve them quickly.
February 5th, 2009, 20:37
In FreeBSD, the ports are to break (like Xorg recently), the system functionality remains. This means, that you can normally login, take out your backups (packages) and undo what you've done, or use an alternative ports tree and install from source. Once the things are settled, you can always update.
In Linux, this is not always true. You can break your system and you won't be even able to login, this almost happened with me on Gentoo with e2fsprogs.
May 16th, 2009, 04:44
Take a time to read and study how it works on freebsd.
After you understood its concepts, create snapshots before doing major upgrades, and if something breaks just restore the partition snapshot and you are good to go. UFS has snapshots as well, but ZFS is having its momentum.... :p
Read portmaster manual. I prefer portmaster also, it oftens resolve dependencies problems that portmanager gets confused about. portupgrade is good too, works with packages if you want, it might be good if you want to use packages often. In my opinion if you want to use freebsd you better use sources. Use binary packages if you are out of time to compile OpenOffice that take 8 hours to build and an average 32bits machine and requires 20gb of free space. Maybe X for example, if you know the upgrade is problematic just keep using the old version.
The secret is run a cron job that emails you the output of portaudit and then upgrade these ports from source, which became available much earlier than packages.
I was a long time Debian user myself and switched to FreeBSD 6 months ago and I am very satisfied with the performance, flexibility and features of O.S. .
Enable this line in /usr/local/etc/portmaster.rc and you will have less problems.
# Save copies of old shared libraries (recommended) (-w)
Most of problems happen when you compile a port with an older library, and after you upgrade that library the filename changes due to the change in version, the program won't find the library and maybe it will affect a feature or the program won't run at all.
After the quirks, it clearly outstands Debian in terms of possibilities.
May 16th, 2009, 22:21
Optional system and user configuration files. The variables set in the script's getopts routine can be specified in these files to enable those options. These files will be read by the parent portmaster process, and all variables in them will be exported.
PLEASE NOTE: In versions before 2.3 /etc/portmaster.rc was recommended. However placing this file in LOCALBASE is the correct thing to do. In future versions of portmaster support for /etc/portmaster.rc will be removed.
Here are examples of variables that are likely to be useful, along with their related options.
# Sample portmaster rc file.
# Place in $HOME/.portmasterrc or /usr/local/etc/portmaster.rc
# Do not create temporary backup packages before pkg_delete (-B)
# Always save the backup packages of the old port (-b)
# Make and save a package of the new port (-g)
# Do not preclean the port's build directory (-C)
# Do not clean the port's build directory after installation (-K)
# Never search for stale distfiles to delete (-D)
# Always delete stale distfiles without prompting (-d)
# Do not run 'make config' for ports that need updating (-G)
# (This unsets --force-config)
# Hide the build and install processes in a log file (-H)
# Arguments to pass to make (-m)
# Recurse through every dependency, and child dependencies (-t)
# Be verbose (-v)
# Save copies of old shared libraries (recommended) (-w)
vBulletin® v3.8.7, Copyright ©2000-2013, vBulletin Solutions, Inc.