Hacker News new | ask | show | jobs
by worklogin 4135 days ago
I really like that FreeBSD has binary package management. I started my journey into Unix almost 10 years ago with FreeBSD Unleashed.

I am considering writing a comparison command-to-command of apt-get vs. pkg, and differences in behavior.

* Are packages from the FreeBSD repos pinned the same way Ubuntu packages are, relase to release? Are there multiple repos (comparable to universe/multiverse, updates/backports)?

  * apt-get update && apt-get upgrade
  * apt-get --no-install-recommends install <pkg>
  * apt-get purge; apt-get autoclean;
  * apt-cache showpkg <pkg>
  * apt-cache search <pkg>
  * dpkg-reconfigure (for post-install scripts)
And so on. If I knew exactly how FreeBSD's pkg system worked related to apt-get, I'd be more comfortable going there full time. I'm also interested in how it integrates with Jails, should I just look in the Handbook for more info, or do you have a blog I should read on it?
2 comments

I want to add that the FreeBSD ports management team is probably too small to handle complicated release management and backporting schemes like you see with RHEL or Ubuntu. That said, nothing stops you from doing it if you wanted. You can set up your own binary package repository using Poudriere. That's what I do; I tend to update everything quarterly unless there's a serious security flaw in something.
Note there are quarterly ports branches you can track if you just want security fixes - you're not just limited to tracking HEAD: https://secure.freshbsd.org/search?project=freebsd-ports&bra...
Awesome. I didn't know about these. Thank you!
Right now, there's only a single package repository for each major FreeBSD release. The ABI doesn't normally change within major releases, so packages built on FreeBSD 10.0 will work on FreeBSD 10.1 (and vice verse).

A pkgng repository can contain older versions of packages, but "/latest" is tree of symlinks to the most recent versions in the repo.

The FreeBSD Ports Tree isn't tagged, so there's nothing equivalent to updates or backports. Sometimes, that means packages won't build on older (or newer) versions of FreeBSD, or it means that the ports infrastructure as a whole won't work properly once you go more than a few releases back. The FTP archive keeps copies of binary packages included with past FreeBSD releases (all the way back to 1.0). Generally, that means everyone using the latest version of Firefox from ports on FreeBSD 9.x, 10.x, and 11.x are going to be running Firefox 35.0.1_1,1. The ports maintainer might include FreeBSD release-specific patches in the package build scripts to handle any differences among currently (or formerly) supported FreeBSD releases.

I don't remember what universe or multiverse contain. If those are the ones that have stuff separated out based on the software package's licensing, ports/pkgng includes logic to handle EULA acceptance for non-free stuff. You can also configure it to _not_ accept a license, in which case packages that use a rejected license will fail to build.

Regarding jails, please see "man pkg". You can give pkgng a jail name or ID, and it will automatically connect to that jail to perform whatever task you asked of it.

apt-get update == pkg update ("man pkg-update"), usually unnecessary

apt-get upgrade == pkg upgrade ("man pkg-upgrade"), automatically updates the repo metadata by default

apt-get purge == pkg delete <pkgname> ("man pkg-delete")

apt-get autoclean == pkg autoremove ("man pkg-autoremove")

apt-cache showpkg == pkg info <pkgname> ("man pkg-info")

apt-cache search == pkg search <pattern> ("man pkg-search")

dpkg-reconfigure does not have an equivalent on FreeBSD. FreeBSD in general takes a default-deny stance on things, so post-package setup usually has to be handled by the sysadmin. There are a few packages that do some interactive post-install setup, but I personally consider this a huge bug (e.g., mail/postfix). Port maintainers generally display post-install setup instructions instead. You can read these via "pkg info". I use the Salt configuration management system, personally.

As for documentation, the FreeBSD Handbook or manual pages are always the first places you should look. There's also some info about pkgng on the wiki, but it's pretty dated as at this point, all of that stuff has been merged into FreeBSD.

Interesting, I'll have to test some of the features to see how they stack up.

In ubuntu, main = FOSS supported by Canonical, restricted = non-FOSS supported by Canonical, universe = community FOSS, multiverse = community non-FOSS.

Those usually don't get updated or messed with except for security. There is also the backports repo for package updates for stable releases.

The short version is that, as I understand it, the FreeBSD Foundation does release engineering different than Canonical or SPI, largely for historical reasons, and that as an end user, you would periodically run "freebsd-update cron" or subscribe to "freebsd-announc@freebsd.org" to check for updates to FreeBSD itself or run "pkg upgrade" to check for updates to third-party packages. It's really, really simple compared to the "good" old days of cvsup and "make world" and roughly equivalent to "apt-get upgrade" or even "apt-get dist-upgrade" (or their YUM analogues).

The FreeBSD equivalent of "main" would be FreeBSD itself, with source/binary updates via freebsd-update or source updates via Subversion. The FreeBSD Ports infrastructure handles package building for _all_ third-party software (Xorg, GNOME, KDE, Emacs, Perl, etc.), which would be the equivalent of "universe" and "multiverse". The Ports infrastructure has integrated license auditing (see https://raw.githubusercontent.com/freebsd/freebsd-ports/mast... and https://raw.githubusercontent.com/freebsd/freebsd-ports/mast...), which allows you to accept or reject licenses at package build time.

There is no equivalent to "restricted". The binary package repository maintained by the FreeBSD Foundation itself only contains free software, meaning that it includes only software whose licenses allow (a) redistribution of the original sources (like an FTP mirror), (b) selling copies of the original sources (like on CD-ROM), (c) free redistribution of the binary package (e.g., via FTP), (d) selling of the binary package (e.g., via CD-ROM), and (e) automatic license acceptance (which would exclude software like dccd that have EULAs which must be accepted prior to compilation/installation).

There is no equivalent to "backports" or "security". Supported FreeBSD releases get regular bugfixes and security updates as described above. As FreeBSD is a volunteer effort, there just aren't enough people involved to make maintaining alternate ports trees feasible. The ports tree does get frozen and tagged at each FreeBSD release to facilitate package building, CD-ROM manufacturing, and FTP distribution, but those tags aren't maintained except as historical markers. If you want security updates, you need to stay abreast of the latest commits the ports tree (whether via portsnap [source], subversion [source], or pkgng [binary]).

> Right now, there's only a single package repository for each major FreeBSD release. The ABI doesn't normally change within major releases, so packages built on FreeBSD 10.0 will work on FreeBSD 10.1 (and vice verse).

And it's worth pointing out that the per-branch repositories are all built from the same sources — ports is not branched. The only reason to have separate release-branched binary repositories is for ABI bumps between stable releases.