Submitted by FreeBSD 6.3-RC2 has been released. “Sorry for the delay with this phase of the 6.3 release. A few glitches were found during testing of the 6.3-RC2 ISOs that included pre-built packages. The 6.3-RC2 builds for amd64 and i386 should now be available on the majority of the FreeBSD mirror sites. I just finished loading the sparc64 build so that will take a little while to propagate to the mirrors. This is the last planned RC for 6.3. Unless a major show-stopper problem is found the release of 6.3 should happen in about two weeks.”
The FreeBSD Project will be very active this month… Two releases (6.3 and 7.0) are coming up. 6.3 is now a “mature” product, and 7 is the “new and shiny” thing.
By the way, 7.0-RC1 is excellent. Already have it installed and running on my test workstation. And it is possible to do a hassle-free binary upgrade to -RELEASE when it is ready. So don’t be afraid to try…
I agree on both counts. 6.X is going to be an excellent branch, and 6.3 will continue this trend.
I have been using 7.0 as -current for about 6 months now on my main home Dell workstation and also on my Thinkpad T42, and I have been really enjoying it. I also have 7.0-RC1 on one of my dedicated servers and it rocks. After managing various other *nix servers over the years, it’s amazing just how great FreeBSD is as a server. From the secure kernel levels, to jails, to the many cool little security tweaks, to the various sysctl options, there are so many sweet features in FreeBSD that I don’t find in other *nix operating systems.
Overall, I am loving FreeBSD these days.
The one thing I love about FreeBSD when I used to run it (now running Mac OS X) is the fact that when you install it, the absolutely *bare* minimum is loaded; if it isn’t needed, it isn’t loaded.
Benefits to be include very fast boot times, even on low powered devices; and much greater security and stability; instead of having everything but the kitchen sink loading at boot up.
Even with Xorg, and the desktop of your choice, it still loads very fast, and the ‘teh snappy’ is awesome. I’m always in awe of the quality of each release; when it is release, it works as it should rather than, “I’ll have to wait 3 months for it to mature” – you can jump into it and feel confident knowing the excrement is not going to hit the fan.
“The one thing I love about FreeBSD when I used to run it (now running Mac OS X) is the fact that when you install it, the absolutely *bare* minimum is loaded; if it isn’t needed, it isn’t loaded.”
That’s one of the most important reasons why FreeBSD is my main OS of choice for servers, workstations and desktops. The minimalistic OS is still highly functional and provides excellent means of diagnostics and maintainance in case of trouble.
“Even with Xorg, and the desktop of your choice, it still loads very fast, and the ‘teh snappy’ is awesome. I’m always in awe of the quality of each release; when it is release, it works as it should rather than, “I’ll have to wait 3 months for it to mature” – you can jump into it and feel confident knowing the excrement is not going to hit the fan.”
Yes, FreeBSD is high quality software in fact. Next to speed, security, standard compliance, straight forward engineering and userfriendlyness, FreeBSD’s quality concept includes tidy source code with excellent comment behaviour, good documentation (manpages, handbook etc.) and overall intelligent concepts of system organisation and implementation. You don’t even need to have an Internet connection to browse the web for wikis, discussion boards and mail archives – you have all your manuals installed and accessible, for system utilities, for configuration files, for system calls, for kernel interfaces and for library functions.
Allthough I won’t stay with the -6- branch and install -7- when the release is available (I’m a bit afraid to use the BETA / RC allthough I didn’t read much about major problems), I think 6.3 will be a great release in the -6- branch, and users of this branch will be able to benefit from the continuous progress in FreeBSD.
I am more a Slackware man for my workstations, but I’ve found myself lately several times installing FreeBSD for servers, and it rocks and flies. I am using a lot too pfSense (FreeBSD based firewall) and it is amazing.
If 6.3 keeps the good road it will be quick, reliable, clean and powerful, what else can we ask ?
that keeps me from moving from CentOS to FreeBSD is updating. Yum update will keep everything up to date and, while it can break things, I have never encountered a serious problem (serious defined as having to rebuild the entire server or losing data, I have had to roll back packages twice).
On the other hand, rebuilding world on FreeBSD seems not to be very wise, not to mention time consuming and tedious (the instructions here: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld…
do not look encouraging).
So the other option to stay current with security fixes etc seems to be to monitor individual ports for updates and install them as they change. That would be a real drag.
But perhaps (almost certainly) I’ve missed something. What’s the easiest way to keep a FreeBSD system current ? Portmanager can take care of installed ports but you still have to recompile the kernel if it needs upgrading, right? I’m willing to trade whatever is gained by compiling per machine for ease of administration.
Edited 2008-01-02 15:32
No, the freebsd-update tools keeps the base system updated with binary updates. No need to rebuild world unless you want to move to another point version or another branch. Even for that, it’s my understanding that freebsd-update will now upgrade you from one point releae to the next as well.
As for ports, you generally have to rebuild those from the ports tree, although you can also set your root’s PACKAGESITE environmental variable to the stable packages for your release (i.e. 6-STABLE) as those packages should be ABI compatible for 6.2, 6.3, etc.
After administering a FreeBSD system for awhile (coming from Debian) it’s really not that bad, especially now that they include the freebsd-update tool. Adding in ccache for faster compiling makes a huge difference. I see no speed difference whatsoever in binary packages vs. compiling, but being able to manually tweak and customize the compile options for ports is what makes the ports system so great. You can build MySQL or Apache or whatever with only those compile options you need and nothing else. It’s extremely flexible and powerful.
“No need to rebuild world unless you want to move to another point version or another branch. Even for that, it’s my understanding that freebsd-update will now upgrade you from one point releae to the next as well.”
The freebsd-update provides a means to update the base system on a binary basis, so it exists to help you avoiding “make buildworld buildkernel” etc. as long as you would tend to use the GENERIC kernel configuration file. For updating the world, there is nothing that the system maintainer changes (e. g. /etc/make.conf), but regarding the kernel, there are users (I may include myself here) who intendedly compile a custom kernel, for example, to have just the hardware drivers in the kernel that exist physically inside the worksation, or to have some kernel parameters tweaked that cannot be set at “runtime level”, for example firewall behaviour, bktr (Brooktree TV capturer) configuration or language settings, such as
options SC_DFLT_FONT
makeoptions SC_DFLT_FONT=iso
options ATKBD_DFLT_KEYMAP
makeoptions ATKBD_DFLT_KEYMAP=”german.iso”
options UKBD_DFLT_KEYMAP
makeoptions UKBD_DFLT_KEYMAP=”german.iso”
Such “strange” things cannot be handled by freebsd-update, as far as I know.
What some people don’t realize, is that while freebsd-update performs an immediate binary upgrade of the base system, it also updates the relevant sources. This is evident from the following line in /etc/freebsd-update.conf:
# Components of the base system which should be kept updated.
Components src world kernel
The immediate impact of this: If you have compiled a custom kernel prior to the update, you only need to recompile / reinstall it (using the same configuration file). This is usually a 10-20 minute process on any recent machine and only requires two commands.
If your plan is to stay to -RELEASE + security patches, you only need freebsd-update and the occasional kernel recompilation. No need whatsoever to make buildworld.
As for ports, once again you don’t really need to upgrade if you don’t have any functionality problem (and the port does not exhibit security problems) you are in no way forced to upgrade. The portaudit program can be used to email you daily on the security status of installed ports.
“What some people don’t realize, is that while freebsd-update performs an immediate binary upgrade of the base system, it also updates the relevant sources. […] The immediate impact of this: If you have compiled a custom kernel prior to the update, you only need to recompile / reinstall it (using the same configuration file). This is usually a 10-20 minute process on any recent machine and only requires two commands.”
I think it’s possible to do it with one command:
# make buildkernel installkernel KERNCONF=MYKERNEL
This is one command. 🙂
“If your plan is to stay to -RELEASE + security patches, you only need freebsd-update and the occasional kernel recompilation. No need whatsoever to make buildworld.”
I didn’t explain it in such a clear way, so thank you, you’re correct of course: Using freebsd-update obsoletes compiling processes except for the kernel, if you want to use a custom kernel.
“As for ports, once again you don’t really need to upgrade if you don’t have any functionality problem (and the port does not exhibit security problems) you are in no way forced to upgrade.”
As I mentioned before, using daily updated ports is interesting only if you’re intendedly planning to use “bleeding edge software”. In most other cases, using the precompiled packages via pkg_add command is the usual way to install software, or, for upgrading, preceded by deletion of the package (not fully elegant, but working; pay attention to dependencies).
I think it’s possible to do it with one command:
# make buildkernel installkernel KERNCONF=MYKERNEL
This is one command. 🙂
Or even more consise :
# make kernel KERNCONF=MYKERNEL
😉
On the other hand, rebuilding world on FreeBSD seems not to be very wise, not to mention time consuming and tedious…
While freebsd-update was already mentioned by others, rebuilding world (the traditional, non-binary method for updating the base system) is consistent and reliable: it just works.
I don’t understand the “not very wise” comment.
>On the other hand, rebuilding world on FreeBSD seems not to be very wise, not to mention time consuming and tedious
Building kernel and world works like a charm, furthermore it’s possible to use binary update too. Many big companies are rebuilding FreeBSD servers since 4.x without reinstalling … don’t try this with *any* Linux distri
Googling freebsd-update provides some interesting information. So as long as I install from the standard source using precompiled packages and do not install from ports at all freebsd-update will keep my system, including the kernel, updated sort of like yum/apt.
I’ll give it a try on a test box.
I’m not sure where you saw that about not installing anything from ports for freebsd-update to work, but I don’t think that’s correct.
As far as I understand it, freebsd-update was included in the base system starting with 6.2, and is now officially supported by the Security Officer and the Security Team. Binary updates are provided through freebsd-update for the main OS, including the kernel.
Since ports is entirely separated from the base OS, I don’t think it matters whether you use ports instead of packages, except for things that are provided in the base as well as ports, like OpenSSL. For those things, keep with the base OS.
In any event, I have a dedicated server that has been running 6.2 for a year, and I have many ports installed, and I use freebsd-update all the time to update the base system and kernel and it works great.
Recent information about using freebsd-update to update major versions is here:
http://www.daemonology.net/blog/2007-11-11-freebsd-major-version-up…
Edited 2008-01-02 17:13
“I’m not sure where you saw that about not installing anything from ports for freebsd-update to work, but I don’t think that’s correct.”
I think so, too. You mentioned correctly:
“As far as I understand it, freebsd-update was included in the base system […]. Binary updates are provided through freebsd-update for the main OS, including the kernel.”
Because FreeBSD has a strict philosophy of dividing between the base OS and additional packages (those things you install via ports or packages, that afterwards reside in /usr/local), the system oriented freebsd-update does not interfere in any way with the additional packages.
For example, if you rm -rf /usr/local, you still have a completely working base OS, but no installed packages.
If you want to use ports and packages side by side, you can use the portupgrade toolset to keep them aware of each other (pkgdb -aF).
“Since ports is entirely separated from the base OS, I don’t think it matters whether you use ports instead of packages, except for things that are provided in the base as well as ports, like OpenSSL. For those things, keep with the base OS.”
That’s right. Just as a sidenode, in most cases it’s the most comfortable thing to use the precompiled packages. The ports are used when you intendedly want to use bleeding-edge software or if you need to tweak options at compile time, e. g. for the mplayer port: which codecs you want to include or if a GUI should be added. In most cases, pkg_add -r is what you need.
“In any event, I have a dedicated server that has been running 6.2 for a year, and I have many ports installed, and I use freebsd-update all the time to update the base system and kernel and it works great.”
Which works perfectly because of the simple reason you have recognized correctly. 🙂
Why is there a 6.3RC2 and 7.0RC1.
Perhaps I have the versioning wrong, but I understood “RC” to mean “release candidate” with release candidates being somewhere in quality between Beta and “Gold”.
Has there been a “final” 6.3 release, and this is just “update 2” of that? Is 7.0 “final” as well, or still in beta (even if very very late beta).
Just confused by the versioning schemes and it seems odd that there would be a 6.x in beta along with a 7x in beta.
The 6.x series will be the stable branch, while the 7.x series will have new bleeding-edge features. Many people won’t migrate to 7.x until the codebase matures a little bit, with the inevitable bugs squashed. It’s quite similar to Microsoft releasing Vista SP1 and XP SP3 at the same time.
The 6.x series will be the stable branch, while the 7.x series will have new bleeding-edge features.
Not quite. 6 IS the current stable branch and 7 will be the new stable branch really soon (if it already hasn’t happened). 6-STABLE will be supported for quite some time (18 months or so after last release of that branch, info available on FreeBSD.org)
6.3RC2 means 6.3 Release Candidate 2, next up the sharp release
7.0RC1 thus means 7.0 Release Candidate no 1 (there will I guess be 2 more RCs)
6 is the currect “STABLE” branch (STABLE has NOTHING to do with what most people assume with stability)
STABLE designates that it is kernel ABI stable that is binary application interfaces.
7.0 is the first release of the new (not yet IIRC) STABLE branch (RELENG_7) and has some very nice new features. 7 is, for my systems, rock solid
“Why is there a 6.3RC2 and 7.0RC1.”
The same way as there are CentOS 2, 3, 4 and 5:
http://centos.org/modules/tinycontent/index.php?id=15
6.3-RC2 means the second release candidate for 6.3. As in, they found errors in the RC, fixed them, and are releasing a new RC. If there are no issues found with RC2, then it will be shipped as 6.3-release.
7.0-RC1 means the first release candidate for 7.0. If there are no errors found in the RC, then it will ship as 7.0-release. If errors are found, they will be fixed, and a new RC will be released.
It’s not exactly rocket science. What’s so hard to understand??
Three things that need updating (if I understand correctly):
1) Kernel
2) Base System
3) Other installed apps
freebsd-update updates 1 & 2 but I’m on my own for 3?
Here’s what I read about freebsd-update:
http://www.daemonology.net/freebsd-update/
What would I gain over RHEL/CentOS for the added pain to keep current? Maybe there is a different philosophy here. Maybe staying current is just a Linux thing. Do people who run FreeBSD need/want to stay current with at least security fixes? How do you do that, for the total system, without having it become a full time job?
There’s always ‘portupgrade -aP’ if you want to upgrade all your installed ports in a binary fashion.
freebsd-update takes care of 1 & 2 as long as you do not recompile anything. If you do, then you are again on your own (which is true with Linux systems too.) There is also a new binary upgrade tool too that lets you easily go from 6.2 to 6.3 or 7.0. I have tested that and it works amazingly well. Again, for this tool to work, you should have a standard install and not something heavily modified.
In terms of ports, you will have to still take care of them. My pointers for port is do not install Xorg or any other graphical monsters. If you want to use BSD as a workstation/desktop, use PCBSD or DesktopBSD. Then use portsnap to keep ports up to date. Use portaudit -Fda to check if there are any security holes. Finally, use portmaster -aug to update all out of date ports and build binary packages for them. I don’t recommend using portupgrade because it relies on a whole bunch of ports and in my experience, keeping it working is a lot more work than keeping my ports up to date.
How difficult is it to update the webbrowsers which come with the default install?
Are they updated as well with the freebsd-update tool?
This is very important, because the browser is a piece of software that has to be updated very often as a result of more or less fatal bugs.
(If you look at http://www.seamonkey-project.org or mozilla.com, there is apparently no FreeBSD version.)
Maybe my question is “silly”, but for me (as a desktop user) this is the main point before installing FreeBSD.
“How difficult is it to update the webbrowsers which come with the default install?”
No web browsers do come with the default install. The default install contains the OS, no GUI or web browsers. Of course you’re free to install them.
For example
# pkg_add -r seamonkey
will install the newest seamonkey version from a precompiled package. These packages reside on the FreeBSD servers and are updated from time to time. If you need “bleeding edge features”, you should use the FreeBSD ports collection and build seamonkey from source.
# cd /usr/ports/www/seamonkey
# make
# make install
Then, if you updated your ports (see comments above how to do this), you can recompile seamonkey as soon as a new version occures:
# cd /usr/ports/www/seamonkey
# make deinstall
# make reinstall
You can automate this process using portsnap, portaudit and portmaster as described above, or use the portupgrade toolset if you like.
“Are they updated as well with the freebsd-update tool?”
No, the freebsd-update tool does only update the base OS, this is the kernel and the userland, or, in other words, everything outside /usr/local where your additional packages are installed.
“Maybe my question is “silly”, but for me (as a desktop user) this is the main point before installing FreeBSD.”
No, there is no silly question. 🙂 I hope I could help you a bit. If you’re going to use PC-BSD or DesktopBSD which install FreeBSD and furthermore a complete KDE desktop and various software, you can use the described update procedures, too, allthoug PC-BSD encourages its users to use their PBI system for package installs and updates.
portupgrade firefox
wait a bit for a source compile or use the -P option for a binary upgrade. Done.
The main packages servers will lag a couple of days to a week behind a point release, but they’re pretty up-to-date for pretty much all software. The package servers are compiling and building packages 24/7.
Edited 2008-01-03 00:10
Many large rollouts of FreeBSD in ISP’s and other similar places have a dedicated build machine that builds packages for all the boxes. On a much smaller scale, this works for the home user, if you have the bits to spare. I use FreeBSD on my home desktop workstation, two laptops, one server, and one offsite server. I also have a crusty old i386 that does nothing but build packages for my machines. I point all my machines to this old box as a local ftp package repository, and it’s binary updates for everything.
So, in the end, I use freebsd-update for binary updates to the base OS, and I use my own binary packages for updates to all my ports on various machines. This way, I can custom build packages with my own chosen compile options, and have easy installation of these binary packages across my network. It’s like the stability of Debian but with current and updated packages.
“In terms of ports, you will have to still take care of them. My pointers for port is do not install Xorg or any other graphical monsters.”
It takes some time to compile “monsters” like Xorg, so using pkg_add to install them is highly recommended, at least if you do not want to set special compiler options for development (e. g. optimization grades, debug symbols) or if you want a 3 button standard mouse to work correctly (needed to modify mouse.c and compile X). Just imagine the joy of compiling KDE and OpenOffice! 🙂
“If you want to use BSD as a workstation/desktop, use PCBSD or DesktopBSD.”
If you are comfortable with KDE or don’t mind to deinstall KDE and reinstall something else, it’s okay. IÄm using FreeBSD as a desktop / workstation since 4.0 and I have always built the system by myself with exactly the applications that I wanted, nothing more, nothing less, so PC-BSD or DesktopBSD definitely are not designed for me. 🙂
“I don’t recommend using portupgrade because it relies on a whole bunch of ports and in my experience, keeping it working is a lot more work than keeping my ports up to date.”
As far as I remember, portupgrade relies on ruby and perl. Perl is already part of the base system.
You are confusing two separate issues: staying current vs. running the latest apps.
On your CentOS box, how do you install and run the latest version of Apache 2.3 without updating to a new version of the OS? How do you install and run the latest version of Samba, without updating the entire OS? How do you install and run the latest version of AppX, without updating the entire OS?
Yes, yum gives you a handy tool for installing and updating apps. However, the only way to install new versions of software is to update the entire OS.
FreeBSD keeps the OS and the APPS separate. There is only 1 ports tree, that lists all the software that is available for use with FreeBSD 5.x, 6.x, 7.x, and 8.x. You can run the latest version of Apache on FreeBSD 5.x, or you can run it on FreeBSD 7.x. The installation method is the same for both.
Just because you want to run a new version of AppX doesn’t mean you have to update anything in the base OS. That’s the beauty of BSD. You can keep a FreeBSD 5.x box in production, updating the apps as they become available, only doing security/bug fixes to the base OS.
As for the “keeping track of what’s installed and has updates available”, it’s a simple matter of installing portaudit, and reading through the weekly security mailings that are sent to root (which you’ve already set as an alias to a real e-mail account, right?). If there’s something listed in there that affects you, then you update that app. Not even close to being a part-time job.
I like FreeBSD but not the ports system and how pre-compiled packages are outdated.
Compiling is time consuming and often problematic. A huge program could be compiling for many hours then suddenly break from the slightest error in the building process.
This has happened to me multiple times when I’ve used FreeBSD and the ports weren’t even labeled as broken.
If it weren’t for that, I would probably use FreeBSD again, once the video and wifi driver support were up to par with Linux.
Edited 2008-01-02 20:10
“I like FreeBSD but not the ports system and how pre-compiled packages are outdated.
Compiling is time consuming and often problematic. A huge program could be compiling for many hours then suddenly break from the slightest error in the building process.”
You’re not forced to compile anything if you don’t want. Outdated precompiled packages? I thought they were updated once a week, shouldn’t that be enough?
You only need to compile something in very few cases, for example if you
– need to set compile-time options (for example for mplayer in Makefile.local),
– want to set optimization flags (/etc/make.conf),
– want to have a custom kernel and world or
– are forced to chance source code to get something working (for example three button standard mouse in X).
In most cases, pkg_add -r is what will be the best solution.
“This has happened to me multiple times when I’ve used FreeBSD and the ports weren’t even labeled as broken.”
I’ve experiened this too, one time, and it turned out that I had a defective RAM module that caused a “one bit off” error so suddenly a path /usr/ports/…. changed into /uss/ports/…. which caused an error.
“If it weren’t for that, I would probably use FreeBSD again, once the video and wifi driver support were up to par with Linux. “
Maybe PC-BSD or DesktopBSD are what you’re looking for? No source contact at all, if you insist on it.
They used to be created once a month. Now they are only created when a new OS version is released, or when major changes happen to the ports tree (like Xorg, KDE, GNOME, libtool, gettext, etc changes hit the tree).
The wifi drivers and wifi support in FreeBSD is far superior to Linux. There may be a few pieces of hardware which aren’t supported, but are under Linux, but this is a small number.
As for video driver they have nvidia binary blobs and the rest are all xorg and platform agnostic.
ATI doesn’t see fit to support FreeBSD, but this is ATI’s problem. I will never buy another ATI card barring nvidia going out of business and then would probably stick to something else.
Xorg has a RadeonHD driver for the R5xx and R6xx chipsets that is based on the documentation and code that AMD/ATI published.
http://www.x.org/wiki/radeonhd?highlight=%28radeonhd%29
They may not support FreeBSD directly, but the are provided documentation helps more then a binary blob would.
The radeonhd driver is available in the ports tree now.
Don’t mess with the configuration (ports per se or make.conf), it’s the first step top break compiling. So in the end _you_ should know what you’re doing and most users are overestimating their knowledge. _Most_ of the time compiling apps _is_ time consuming, but works like a charm!
“Don’t mess with the configuration (ports per se or make.conf), it’s the first step top break compiling. So in the end _you_ should know what you’re doing and most users are overestimating their knowledge.”
Isn’t “know what you’re doing” a universal principle in computing anyway? 🙂
You’re right of course, most settings are okay by default and need changes only if you intendedly want to do something extravagant.
“_Most_ of the time compiling apps _is_ time consuming, but works like a charm!”
Yes, that’s true. In most cases, using precompiled packages via pkg_add is faster. As I mentioned before, most users would tend to use these packages instead of building ports from source because of this reason, but when you’re forced to use the ports, they do work great, at least from my experience.
By the way, compiling things like X, KDE or OpenOffice from source is a good test for your system, how it handles CPU load / swapping, and maybe an indication for faulty RAM modules, so if compiling fails without understandable reason (for example, compile break beacuse something in /uss/src could not be found), go check with memtest. 🙂
Maybe a more important principle is “admit to yourself what you don’t know”.
It’s also a good test of your sanity
“Maybe a more important principle is “admit to yourself what you don’t know”.”
Hey, I’m a Computerprofi and Expert because I read the Computer-BILD! 🙂
“[Compiling X or KDE is] also a good test of your sanity
“
And your patience. 🙂
If you want a more Linux-like experience with FreeBSD, then just use pkg_add -r to install everything. You will get packages that were created when the OS was released, however long ago that was. Same as you get with just about every Linux distro out there (ie, no updates until the next OS release).
Then, when the next version of FreeBSD is released, use freebsd-update to do a binary update. Then use pkg_add -r or portupgade -PP to install/update using the new packages.
Voila! You can now use FreeBSD just like it was any other Linux distro.
The easiest (most yum/apt-alike) way to keep a FreeBSD system up to date, with no compling.
1) Install only standard (not custom compiled)kernel, base system.
2) Install other software from prebuilt packages.
3) Keep kernel and base current with freebsd-update.
freebsd-update fetch
freebsd-update install
4) Update other installed packages with what? pkg_update looks like it only does one package at a time. Is there a way to upgrade them all at once?
4) Update other installed packages with what? pkg_update looks like it only does one package at a time. Is there a way to upgrade them all at once?
# man portupgrade
# portupgrade –use-packages-only –all –yes
This could alternately be “portupgrade -PPay”.
I didn’t think to use portupgrade to update packages. Ports are ports and packages are packages. Confusing to us noobs.
I didn’t think to use portupgrade to update packages. Ports are ports and packages are packages. Confusing to us noobs.
Anyway- you can make your own updated packages from ports. Look into /usr/ports/packages for compiled binaries later.
# man portupgrade
-p
–package
Build a package when each specified port is installed or upgraded. If a package is upgraded and its dependent packages are given from the command line (including the case where -r is specified), build packages for them as well.
“I didn’t think to use portupgrade to update packages. Ports are ports and packages are packages. Confusing to us noobs.”
No no, not confusing, maybe I’m allowed to donate some education here. 🙂
What’s the difference between a port and a package?
A port can be seen as a set of small files that describe a piece of software and the operations you can do with it. These files are handled by the make command or by programs that utilize it, for example the portupgrade tools.
These files are organized in a hierarchy, usually /usr/ports with further subdirectories for categories (www, irc, german, sysutils, x11-wm etc.) that contain a directory for each port.
These files usually are:
Makefile
README.html
distinfo
pkg-descr
pkg-plist
I’m sure you can figure out what they stand for. In most cases, they are not touched by the user in any way.
As I mentioned before, a port is more than an interface to build something from source. Let me just mention some things you can do with a port:
Update the ports collection:
# make update
Fetch the source code (or binary archive, if no source code is distributed):
# make fetch
Extract the source code:
# make extract
Apply local patches:
# make patch
Build a certain port:
# make
Install the port:
# make install
Uninstall the port:
# make deinstall
Reinstall the port (after deinstalling it):
# make reinstall
Create a package:
# make package
Delete working files
# make clean
(For “make update”: Traditionally it used cvsup to update the ports collection, but you are encouraged to use portsnap for this purpose.)
And now you know what a package is: A package equals a port that has been compiled. For example, when you
# pkg_add -r xmms
a precompiled version of xmms will be retrieved automatically and then be installed on your system. The same thing could be achieved if you
# cd /usr/ports/multimedia/xmms
# make install
but here, you build from source yourself. And as you see, you don’t need to do the many steps (or correct: possibilites) by hand because “make install” implies all of them that are neccessary.
Maybe you’re questioning why the ports do exist or who could use them. In most cases, pkg_add is what you want to easily install software (without needing to know where it is available, without downloading it manually, without having to use a browser etc.). But if you are required to build something from source or if you intendedly want to do it this way, for example, if you want to use “bleeding edge features”, if you want to apply custom flags via Makefile.local (e. g. codecs and GUI mplayer should have compiled in) or if you want to request a certain optimization (/etc/make.conf), And, of course, if you want to patch the source code in order to get something working (e. g. three button standard mouse in X). You are not forced to use a port, the only exception is software that may not be packages due to licensing reasons (early versions of mpg123, if I remember correctly).
For example, if you want to tweak mplayers’s builtin features, you create the file
/usr/ports/multimedia/mplayer/Makefile.local
with flags like
WITH_VORBIS=yes
WITH_LANG=yes
WITH_DVD=yes
WITH_OPTIMIZED_CFLAGS=yes
WITHOUT_RUNTIME_CPUDETECTION=yes
CFLAGS+= -O3 -pipe -mfpmath=sse -ffast-math
That’s a part of an ill configuration, so don’t try this at home. 🙂
I want to come back to the portupgrade toolset. It has a useful feature if you are going to use ports and packages side by side and want to avoid dependency duplications and interferences with installed software. The pkgdb command you usually use as
# pkgdb -aF
checks installed packages and takes care for possible interferences between using ports and packages. The portinstall tool can be used to automate using features of the ports collection, for example automatic updating of everything as it has been mentioned before. It can imitate the functionality of pkg_add, for example
# pkg_add -r audacity
and
# portinstall -P audio/audacity
will install audacity from a precompiled package, while
# portinstall audio/audacity
will build from source using the ports entry. But you can keep a copy of the compiled port – which is a package then – to install it on other systems, so when you
# portinstall -p audio/audacity
you will have a file /usr/ports/packages/All/audacity-1.2.3.tbz that you can transfer to another system and install it via pkg_add.
In a result, you can use portupgrade to upgrade installed software, no matter if you installed from ports or from packages, utilizing either building from updated source (ports) or updating via binary packages. The portupgrade tool offers the equivalent options so you can automate the process.
I hope this has been a bit interesting to you, and if not so, at least for others. This lesson is concluded, stand up, bood gotov, vsyegda gotov. 🙂
Edited 2008-01-03 20:38
Packages are just “pre-compiled ports, in a nice binary archive”. They are built from the same ports tree, and normal users can create their own packages (make package, or pkg_create). They are not separate, and should not be thought of as separate, and they should not be treated separately.
One (packages) is just an extension of the other (ports).
The end result is the same thing, the same files get put on the harddrive, and the same entries are added to the package database (/var/db/pkg).
Packages are ports that have been compiled and ports are a set of instructions for compiling software.
Assume that one installed the kernel, base system and other software from precompiled packages, should there not be a single program to manage all of those kinds of software instead of two (freebsd-update for kernel and base and portupdate for everything else). Software is software whether its the kernel or httpd, so why not one place to manage all software installed from precompiled packages?
Seems darned close to apt-get update, apt-get upgrade, or yum update.
should there not be a single program to manage all of those kinds of software … why not one place to manage all software installed from precompiled packages
Because you keep forgetting the FreeBSD philosophy of separating the base system from third-party addons. The FreeBSD operating system is the kernel, base, and userland. That’s it. That’s all you need to get a full fledged operating system up and running. For the most part, it is all developed in-house. Thus, it makes sense for there to be a tool to update that operating system. FreeBSD itself does not include ports.
The ports system, on the other hand, is separate from the FreeBSD operating system since it contains tools to build third-party software like Apache, Xorg, KDE and the like. FreeBSD installs ports in /usr/local even, to keep the separation nearly complete. The ports tree is managed outside of the base, so it makes sense to have separate tools for that.
Also, remember the old Unix philosophy of using one tool to do one thing well.
Edited 2008-01-03 23:02
“Packages are ports that have been compiled and ports are a set of instructions for compiling software.”
Not just compiling; installing, creating binary packages, deinstallung, updating, patching etc., too, see my comment above.
“Assume that one installed the kernel, base system and other software from precompiled packages, should there not be a single program to manage all of those kinds of software instead of two (freebsd-update for kernel and base and portupdate for everything else). Software is software whether its the kernel or httpd, so why not one place to manage all software installed from precompiled packages?”
Regarding the base OS, it doesn’t matter if you install from precompiled packages (sysinstall / freebsd-update) or from source (make). The result is the base OS everywhere outside /usr/local in binary form.
Regarding additional software, it doesn’t matter if you install from precompiled packages (pkg_add / portinstall -P) or from the ports collection (make). The result is a piece of additional software inside /usr/local in binary form.
So why is there a difference between the base OS and the additional software? FreeBSD has a concept of separating the base OS (everything outside /usr/local) from any additional piece of software, or “third party stuff” (everything inside /usr/local). The ports collection has many maintainers who care for their certain ports, while the base OS is maintained by the FreeBSD staff directly. Maybe this concept of distinction between base OS and anything else is a possible reason. Things regarding the OS require much more accuracy and precision because an error could render your system unusable, while errors in the ports system don’t affect your OS at all.
I think that’s a possible reason, but I don’t know exactly about details, so let’s assume I’m right. 🙂
“Seems darned close to apt-get update, apt-get upgrade, or yum update.”
Yes, I think there are similarities. I can’t tell how similar they are to FreeBSD’s update mechanisms because I don’t use much Linux.
Close enough.
Bzzzt! That’s where you are messing yourself up. There are no “precompiled packages” for the base OS. The base OS is just that: the base. It’s what’s installed from the CD. There are no packages for it.
This is not a Linux distro where the distro maker just grabbed packages from here, from there, from over here, over there, wherever, and glues them together.
The FreeBSD OS is managed from a single CVS tree. Everything that goes into FreeBSD is in that tree. The complete source for that is shipped in /usr/src. Everything is there. This is the base OS.
To update the base OS, you either:
a) update the source tree, and compile the world, or
b) use freebsd-update to do the same thing without compiling
You need to stop thinking like a Linux user where the “OS” is nothing but a large conglomeration of packages loosely glued together and shipped.
FreeBSD is a complete OS, developed by a single group. There is a clear separation between “the base OS as shipped on the CDs” and third-party apps you install on top.
2008 and forward going to FreeBSD and *BSD years, just watch it
Indeed… I would like to see NetBSD up there as well as FreeBSD in the top 10-12 on distrowatch, one too many Ubuntu and Debian derivatives out there. I’ve been using FreeBSD since 6.2 and I’m very impressed with how it has come along, NetBSD since 3.0… love the pkgsrc. I’ll never give up Slack or Arch, less they fall away.
Good work FreeBSD!