freebsd-update vs rebuilding world

beiroot

beiroot

Hello Experts,
I've read a lot about *BSD lately, especially about FreeBSD. I've decided to give it another try. To be honest I never used it a lot, so let's say it's my first time - I'm a noob.

Could you please tell me what is the difference between updating FreeBSD with freebsd-update vs doing so with rebuilding world? It is like pkg vs port idea? The handbook leaves me with no answer.

What is more, do you guys know where I can find some reading on BSD architecture or generally OS architecture, or BSD vs other OS architecture (I've read the handbook :)). No big idea behind this, just for the sake of theory and knowledge - I'm a theory type of guy :)
 
beiroot said:
Could you please tell me what is the difference between updating FreeBSD with freebsd-update vs doing so with rebuilding world? It is like pkg vs port idea?
Click to expand...
That's pretty much it, yes. Using freebsd-update(8) it downloads pre-compiled binaries that are installed. It's quick and easy to use but only works for -RELEASE versions. Building world involves getting the sources and compiling everything yourself. It's slow and tedious but allows a lot more freedom to change things. You're also not limited to -RELEASE versions, it can be used to update any version at any revision level.

beiroot said:
What is more, do you guys know where I can find some reading on BSD architecture or generally OS architecture, or BSD vs other OS architecture (I've read the handbook :)). No big idea behind this, just for the sake of theory and knowledge - I'm a theory type of guy :)
Click to expand...
"The Design and Implementation of the FreeBSD Operating System" (2nd edition) is highly recommended.
https://www.amazon.com/Design-Implementation-FreeBSD-Operating-System/dp/0321968972
 
When you rebuild from source, you compile the source locally and install what you compiled. With freebsd-update, you don't compile yourself, but fetch binaries and other OS files.
 
Building world is definitely recommended if you want to tinker with things. Although it can be slow and tedious it's actually surprisingly simple to do. The instructions in the handbook are quite straightforward, once you've done it a couple of times it's not that much more difficult than running freebsd-update(8). Depending on your hardware it can take a couple of hours to complete. But there's something hauntingly mesmerizing about watching compiler output scroll by :D
 
SirDice said:
Depending on your hardware it can take a couple of hours to complete. But there's something hauntingly mesmerizing about watching compiler output scroll by :D
Click to expand...

Oh yeah, I love it too. Logging in or watching compiler or generally speaking screen console output makes my inner geek very happy:D

cpm@ said:
For building world and kernel I recommend wblock@'s article:

http://www.wonkity.com/~wblock/docs/html/buildworld.html
Click to expand...

I actually read this article, but thanks :)

BTW, I don't know if any of you guys is a FreeBSD Handbook contributor/author, but maybe it would be nice to add some short explanation on freebsd-update vs. rebuilding world. Just to clarify and explain.
 
beiroot said:
BTW, I don't know if any of you guys is a FreeBSD Handbook contributor/author, but maybe it would be nice to add some short explanation on freebsd-update vs. rebuilding world. Just to clarify and explain.
Click to expand...

Yes, wblock@ is the person you're looking for.
 
This is a small side-comment, still ontopic though...

beiroot said:
What is more, do you guys know where I can find some reading on BSD architecture or generally OS architecture, or BSD vs other OS architecture (I've read the handbook :)). No big idea behind this, just for the sake of theory and knowledge - I'm a theory type of guy :)
Click to expand...
You might like developers handbook as well as the architecture handbook.

Maybe fun to know: it's also very easy to get this documentation on your own setup. And I'm not just talking about the static packages which you can download and extract (for example by installing misc/freebsd-doc-en), but to get the source code and then compile that into whatever format (plain text, HTML, PDF, etc.) or language you'd like to have. I realize that this maybe overdoing it a little bit if you only want the documentation, but it also happens to be my favorite way of getting the documentation on my environment.

All you basically need is textproc/docproj so that you can actually process the documentation source, and of course you'd need to use svn to check out said documentation source (check out as in get a local copy of it on your computer).

If this sounds appealing to you then the Documentation Project Primer might be in interesting read also.

Like I said: it's not really necessary, you can easily grab the documentation port and be done with it, but I personally prefer to keep my local copy up to date this way, also because it somewhat fits in with getting the system documentation (manual pages and the likes) by getting the OS source code and compiling the world.

Hope this can also help you out a bit (or at least give you some ideas ;)).
 
wblock@ from what I've read that's a completely new feature, not available to play with in 10.3, right? What would be difference/advantage over freebsd-update?

ShelLuser, you partially answered my next question, thanks:) So if I want to stay up do date with the documentation I just use the sources and check for updates once in a while. But I could do the same with packages, right? Just update them via freebsd-update for example.

What about the webpage handbook? Do you have a newsletter saying "hey, we've changed the handbook, take a look at it"?
 
Last edited by a moderator:
beiroot said:
What would be difference/advantage over freebsd-update?
Click to expand...
It would work the same as packages do now, there are just packages for the operating system in addition. No separate system for base system upgrades, people are already familiar with it. However, it was not ready for 11.0, so it's not available at all yet.

We do not have notifications for documentation updates. Partly that is because they are incremental and many changes are not worth an update notice. Partly it's just because we have never done it and have extremely few people working on documentation. More are always welcome.
 
wblock@ said:
It would work the same as packages do now, there are just packages for the operating system in addition. No separate system for base system upgrades, people are already familiar with it. However, it was not ready for 11.0, so it's not available at all yet.

We do not have notifications for documentation updates. Partly that is because they are incremental and many changes are not worth an update notice. Partly it's just because we have never done it and have extremely few people working on documentation. More are always welcome.
Click to expand...

However, the docs still get version bumps from time to time, correct? I have misc/freebsd-doc-en installed as a package on my systems and once in a while I see it getting upgraded :). I would also be interested in writing some documentation on the things I typically tinker with (browsers, minimalist setups, etc.). The only thing keeping me away was the dreaded "distro-hopping syndrome" I suffered from a while back.

Good to see an initiative to merge system updates with package updates (pkgbase). I'll probably read more about this also. Don't want to hijack the thread, though :).
 
The doc ports are a special case. I'm pretty sure they just encapsulate building docs locally, but can't recall. Unless you have no network connection, the online HTML versions of the docs are best. They are built from source hourly or even more often.
 
Guys,
one more thing has come to my mind while playing with pkg vs. ports. From what I can read in the Handbook and test on the system, it is possible to install something using ports and upgrade or delete it using pkg? I thought these are two completely different ways of dealing with software. (Although I know package is in fact precompiled binary, right?)
Does it work only this way: port->pkg or it can be the other way round too? Why is that possible? I mean it's cool, but why? :)
 
beiroot said:
From what I can read in the Handbook and test on the system, it is possible to install something using ports and upgrade or delete it using pkg? I thought these are two completely different ways of dealing with software. (Although I know package is in fact precompiled binary, right?)
Does it work only this way: port->pkg or it can be the other way round too? Why is that possible? I mean it's cool, but why? :)
Click to expand...
The only main difference between installing using the Ports collection or installing using pkg-install(8) is the source material. In other words: the Ports grabs the original source file, optionally applies some patches to make things 'fit' and then compiles & installs it. pkg-install simply downloads a pre-compiled binary and then also simply installs it.

The key here is the installation process: both use the FreeBSD package manager (pkg) so both methods more or less result in the same thing: having the software installed and manageable through pkg.

So yes, if you installed something through the ports collection you can simply use pkg to delete it, no problem. You could also opt to go to the Port directory itself and use # make uninstall but all that basically does is fall back to pkg.

Now to your question... Yes, it is possible to install something through the Ports collection and then upgrade it using pkg. But the end results may not be what you're looking for, depending on what software we're talking about. Dependencies could get broken, other programs may stop working because of changed options, etc.

In general you should not mix both upgrade options casually. Just because you can use something doesn't always mean it's also feasible to actually do so.

(edit)

Forgot the why part... This is possible because in the end one package manager is used (pkg). So if you install something through the Ports collection it'd still end up in your regular package database from which pkg-install can also get information from and compare that to any available packages in the repository. Then determine if a version is newer or not.

Same applies the other way around. If you have a binary package installed you can easily re-install the whole thing using the Ports collection, because it would simply re-install (or upgrade) and manage the existing software through the package manager.

But as mentioned earlier: it's best not to mix these two types of updating.
 
A port builds a package and it's this package that gets installed. So from the system's point of view there's no difference between a port or a package. Care must be taken though, the official package repositories have packages that have been built using default options. When you mix ports and packages this can bite you when a dependency port is built using non-standard options.

To prevent this I can highly recommend setting up your own repository with ports-mgmt/poudriere or ports-mgmt/synth. This will allow you to build custom packages, deviating from the defaults, while keeping the ease of use of packages.
 
I second SirDice's suggestion to use ports-mgmt/poudriere or ports-mgmt/synth for a second, important reason. You will see fewer build errors than if you build your own packages on a live system. Because Poudriere and Synth use pristine build environments, rather than live systems to build, you won't see errors because you, for example, had package X installed and that caused an automake script to turn on some untested option.
 
What about the disk use? I compared installing Xorg with ports and package. The first method used enormous amounts of diskspace while the second one just as much as you expect it to use. To be fair though, I must add that while I compiled it I had 1024MB on my VM and when I installed a pkg I upgraded to 2048MB (both times - 512 MB swap from the default VM install). Nevertheless, compilation used gigabytes of diskspace. Is it normal or is it just me/my VM?
 
Note that building from ports also installs a port's build dependencies. Packages don't have build dependencies as they don't need them (they're already built).
 
make clean in a port will remove all the temporary work directories. Or make distclean gets rid of those and the distfiles, which can take a fair bit of space. Outdated distfiles stick around, too, unless you delete them. ports-mgmt/portmaster can clean out unused or obsolete distfiles.
 
I want to add a little bit to what has been said above: ports-mgmt/portmaster is in my opinion an excellent tool which can help you control basically all parts of installing using the ports collection. After installation you'll get a file called /usr/local/etc/portmaster.rc.sample in which you can configure everything you want Portmaster to do.

This includes clean up tasks such as removing ports which are only 'build dependencies' but also helpful features such as making a backup package of your existing one before installing a new one. So should something go wrong you can always fall back to the previous version.

Finally, a good example to illustrate what has been said above is by using # make run-depends-list in a ports directory, this will show you all the required files to actually 'run' (use) the port. Now if you use # make build-depends-list you'll get an overview of everything needed to build the port. See the ports(7) manualpage for a more complete overview of those make targets.
 
You must log in or register to reply here.
Back
Top