Installing updates

If I recall, 6.0 was new the last time I tried FreeBSD. I tried it because the Linux kernel could not boot on that hardware but FreeBSD had no trouble at all. There were three things I did not like, but only one is on topic for this forum section.

A fairly low level library had an important security update. The release notes for the update (notes from FreeBSD, not that individual library) said everything depending upon it would have to be rebuilt. And that turned out to be just about everything. It took me a whole day to recompile a hundred or so libraries and applications. I never did another major update on that box which is now long retired.

Now that some time has passed, I was wondering about the update experience today. Is it less arduous now than it was then?
 
I don't know whether this was different back then (being a new user right now), but the obvious answer would be: with binary packages, you won't have this hassle. With building your own ports, using build-time configuration, you will. There really is no way to magically change this.

It's actually not even different from Linux systems. Some even include a ports tree (which is, in fact, just a convenient way to allow building your own packages easily), but all allow to build packages from source. In such a case, you'd be forced to rebuild all these packages, too.
 
At that time, the recommendation was to choose either ports (DIY compile) or packages (binary), but not to use both. Very few packages existed, so ports was effectively the only choice. There were perhaps 15000 ports compared to 100 or so packages.

It would not have been so bad if I did not have to get so involved with it all. I had to identify the libraries that depended on that key library and recompile them. I also had to identify applications that depended on that library but nothing else and recompiled them. Then I had to identify what depended upon the libraries that depended upon the key one and recompile. Eventually I got to recompile the big things like Samba and Firefox. It would not have been so bad if it could have been more automated, and it would not have taken quite as long without my continual participation. I ended up making handwritten notes to keep track of what got done, what was to be done, and in what order. I had to keep looking back at the screen to see if it had stopped scrolling, thus telling me it was time for the next compile. Every compile went well and the system worked just fine when I was done. I even continued doing updates that were less extensive.

I do have the luxury of scheduled downtime not being all that disruptive. If it took six hours to compile 200-300 ports, that's probably ok if I could start it and walk away. Yes, I would still keep an eye on things. But back then, I was never free for more than a few minutes until I got to the biggest compiles. Samba and Firefox each took over two hours to compile.

Do FreeBSD ports still use imake? I didn't hate it (I actually kind of liked it). A few months ago I got a tarball for my Debian Wheezy box (no package available), but I was stopped dead in my tracks upon finding it required using imake.
 
(Deleted by user rmoe because DutchDaemon seems to think that picky 100% sticking to formal rules is more important than content)
 
Packages have been available at least from 3.0 onwards (when I started with FreeBSD). Granted the package system had its quirks, it wasn't easy to upgrade packages for example. Ports like sysutils/bsdadminscripts made it a bit better but it was still a pain. As for upgrading through ports, ports-mgmt/portupgrade has been available for ages.

I suggest you try one of the recent versions and, in particular, the new PKGNG system. Compared to the old pkg_* tools, PKGNG is a breeze. There's still a lot of work being done on it but it has improved the installation and maintenance of packages a tremendous amount.
 
Since FreeBSD 6, some things have changed. Hardware is much faster, so if you choose to compile things, it takes less time. ports-mgmt/portmaster solved many of the problems of ports-mgmt/portupgrade. pkg has revamped the package system, and binary packages are now better supported and growing.

imake was only used some ports, mostly the old X11 system, and only a few still use it.
 
YMMV. I've one v9 machine that pkg2ng failed to convert and upon implementing a workaround there are serious bugs remaining. This machine, is has/does save a lot of time, considerably, but is prone to breakage. For example, to now install sysutils/sec the command pkg install sec wants to install several unrelated ports; I 've a one cli >> three cli workaround in place but am waiting to see if this particular problem goes away at the end of this week when a new database becomes available. So here at least it can be considered easier but not as reliable [as far as something I can put into a one-liner and run more or less unattended]
as of yet, still a tradeoff. I see its potential, however, as still surpassing the other two operating systems I have had years of experience with.
 
I highly recommend building your own packages. It's something I have been doing ever since jails became available. At first I started with just a simple, clean, jail. Then built all my packages using portupgrade. The resulting packages I used to 'upgrade'. I say 'upgrade' but it was actually a pkg_delete -a and a re-install of the stuff I needed. I've used that system up until just fairly recently. I even built PKGNG packages that way (now I just do pkg upgrade and I'm usually done). It's a great way to customize every port's options while keeping the ease of installing packages. Even if you only have one system it will pay off. True, you'd still have to compile and build everything which will take time. Depending on your hardware even a lot of time. But you're not touching the 'host' system you need to work on. There's no risk of things crashing half way through a particularly annoying library upgrade. There's less risk of that anyway because you start with a clean system. If it it did crash and burn it will do so inside the jail. You can fix the issue or just start over. Giving you ample time to find a solution before you start updating the system you need to have working at all times.

If you do have a few more systems to maintain I can highly recommend ports-mgmt/poudriere. It's what I'm using now and it's been brilliant in combination with pkg(8). So far I haven't ran into an issue I wasn't able to get quickly resolved. I have set it up for one of the companies I work for and it's been serving packages for about 25-30 servers without issues there too. I obviously do test my packages before using them in production. But again, you can build packages, tweak settings before you start touching stuff that's making the money that actually pays for the job :D
 
I highly recommend building your own packages. It's something I have been doing ever since jails became available. At first I started with just a simple, clean, jail. Then built all my packages using portupgrade. The resulting packages I used to 'upgrade'. I say 'upgrade' but it was actually a pkg_delete -a and a re-install of the stuff I needed. I've used that system up until just fairly recently. I even built PKGNG packages that way (now I just do pkg upgrade and I'm usually done). It's a great way to customize every port's options while keeping the ease of installing packages. Even if you only have one system it will pay off. True, you'd still have to compile and build everything which will take time. Depending on your hardware even a lot of time. But you're not touching the 'host' system you need to work on. There's no risk of things crashing half way through a particularly annoying library upgrade. There's less risk of that anyway because you start with a clean system. If it it did crash and burn it will do so inside the jail. You can fix the issue or just start over. Giving you ample time to find a solution before you start updating the system you need to have working at all times.

If you do have a few more systems to maintain I can highly recommend ports-mgmt/poudriere. It's what I'm using now and it's been brilliant in combination with pkg(8). So far I haven't ran into an issue I wasn't able to get quickly resolved. I have set it up for one of the companies I work for and it's been serving packages for about 25-30 servers without issues there too. I obviously do test my packages before using them in production. But again, you can build packages, tweak settings before you start touching stuff that's making the money that actually pays for the job :D

This really is solid advice. Another small added benefit of using this method of upgrading is no build dependency clutter on the host system. You have absolutely nothing more than needed/wanted installed to run. :)
 
Back
Top