6 ms·

That's a good overall article - I've been switching back and forth between FreeBSD and Debian for several years now, and I never spend more than a couple of mon

by penland 12y ago

That's a good overall article - I've been switching back and forth between FreeBSD and Debian for several years now, and I never spend more than a couple of month without using one of them. The one thing that surprised me was his take on FreeBSD's package management system, pkg. PKG is relatively new, having been released in late summer 2012. Prior to that, FreeBSD relied on the ports collection, which was (is) a vast tree of Makefile's allowing you to create custom builds of virtually any software imaginable. While pkg is still raw on the edges, I VASTLY prefer it to Debian's hodgepodge of package management tools that all do 90% of the other, though none of them do it cleanly and none of them have straightforward interfaces. Am I using dpkg here? What about aptitude? Or should I just roll w/ apt-get? All of these tools combine the ease of use of git with the flexibility of a Maven build. If you know how to use to descend deep into the depths of git or Maven, this isn't an issue ( and for the author, it certainly is not ). Yet there are numerous simple tasks ( like say, searching for a package remotely when you aren't sure the exact name ) which still require hitting up google and settling in for a Click-Your-Way-To-Adventure session. PKG, in contrast, is both simplistic and flexible ( it reminds me of a industrial grade version of Brew in some sense ). It's a tool that I find myself integrating into my workflow beyond simple installs / updates, particularly it's seamless integration with jails. Configuration of remote repositories is vastly simplified as well. PKG is not perfect by an means - it definitely has worts that need to be taken care of. I'm also sure that PKG probably feels a tad inadequte to some hard core sys admins - pkg has the look and feel of a tool designed by a programmer looking to handle normal cases than a tool designed to provide a sys admin with an atom bomb if necessary. Yet the system is still relatively new and as the bugs continue to get ironed out it's a reminder to me of why I love FreeBSD in a lot of ways - the abstraction point is flawless and it gets out of my way.

Volundr 12y ago
For at least as long as I've been using it (7+), FreeBSD has always had binary and source packages. Ports are still very much existent and supported (and needed if you want anything custom). All pkg replaces is the old way of getting/managing binary packages (pkg_add, pkg_delete, pkg_info, etc).
- penland 12y ago
  You're 100% correct. Sorry about that, my fingers didn't translate what I had in my head in regards to pkgng replacing the old separate multi-component way of handling binary packages. My understanding was that pkgng is a architectural overhaul in addition to a simple client clean-up - configuration is different for example. What I was trying to get to was that the newer design is barely two years old in production. I should have written this more clearly and did not, thanks and sorry.
worklogin 12y 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?
- xenophonf 12y ago
  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.
xenophonf 12y ago
pkgng + poudriere = my sysadmin sweet spot. I can customize package builds to my heart's content while continuing to use the FreeBSD package repositories (if I want). It'd be nice if pkgng would build stuff from the ports tree if necessary, like MacPorts does, but frankly pkgng is good enough as is. If I need more than FreeBSD's binary package set, I'm comfortable with building directly from ports (in case of one-offs) or expanding my Poudriere deployment. Compared to pkg_install/portupgrade/portmaster, pkgng is awesome---flawless binary upgrades, even from my custom package repository. Compared to YUM/APT, pkgng is still awesome---setting up a custom repository and automating package builds is pretty easy, especially compared to Spacewalk (which I want to like, I really do).
- feld 12y ago
  That's on the roadmap. Eventually pkg will auto build only what is necessary to update your custom packages from ports when you do a "pkg upgrade".
aerique 12y ago
I've been using "dselect" for 15+ years on Debian now :-) But it is not simplistic.
glandium 12y ago
"Am I using dpkg here? What about aptitude? Or should I just roll w/ apt-get?" Just use "apt". It's new to Jessie, though.
weland 12y ago
Do you know of a non-broken way to build ports with many dependencies? This has always been my biggest annoyance and one of the things that constantly made me pick the cough other BSD. Whenever something that I need isn't in the package set, all hell breaks loose: most ports seem to have most options turned on by default (generating a lot of dependencies) and there seems to be no easy way to select configuration options prior to starting the whole build process -- so I end up having to sit for the next two hours, pampering the build process and tuning (actually, mostly disabling) options every time it moves on to the next port. Needless to say, this isn't fun, especially since there's no easy way to tell what dependencies an option is going to pull (I remember being able to retrieve that information through a script I cobbled up but...). I could probably script it to just go ahead with the default dependencies, but that gives terrible results (I try to install this little console tool and now it's pulling gnome-something-something because the console tool can be integrated with ImageMagick and that's compiled with support for this-weird-format which is provided by this-weird-lib which is part of the Gnome project and now I'm slowly compiling half the packages in Gnome even though I don't use a single program from the Gnome project).
- rvanlaar 12y ago
  You could run: make config-recursive a couple of times to do the configuration up front. See also: https://www.freebsd.org/doc/handbook/ports-using.html https://www.freebsd.org/doc/handbook/ports-using.html
  - weland 12y ago
    It's what I usually do, but it's still annoying as hell when more than a dozen packages are involved in the build chain :(.
- Freaky 12y ago
  Add OPTIONS_UNSET=gnome to /etc/make.conf, plus whatever other options you want excluded system-wide. Ditto OPTIONS_SET. You can override for specific ports with ${PORTNAME}_SET/_UNSET too.

by penland 12y ago

Volundr 12y ago

For at least as long as I've been using it (7+), FreeBSD has always had binary and source packages. Ports are still very much existent and supported (and needed if you want anything custom). All pkg replaces is the old way of getting/managing binary packages (pkg_add, pkg_delete, pkg_info, etc).

penland 12y ago
You're 100% correct. Sorry about that, my fingers didn't translate what I had in my head in regards to pkgng replacing the old separate multi-component way of handling binary packages. My understanding was that pkgng is a architectural overhaul in addition to a simple client clean-up - configuration is different for example. What I was trying to get to was that the newer design is barely two years old in production. I should have written this more clearly and did not, thanks and sorry.

worklogin 12y 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?

xenophonf 12y ago
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.

xenophonf 12y ago

pkgng + poudriere = my sysadmin sweet spot. I can customize package builds to my heart's content while continuing to use the FreeBSD package repositories (if I want). It'd be nice if pkgng would build stuff from the ports tree if necessary, like MacPorts does, but frankly pkgng is good enough as is. If I need more than FreeBSD's binary package set, I'm comfortable with building directly from ports (in case of one-offs) or expanding my Poudriere deployment. Compared to pkg_install/portupgrade/portmaster, pkgng is awesome---flawless binary upgrades, even from my custom package repository. Compared to YUM/APT, pkgng is still awesome---setting up a custom repository and automating package builds is pretty easy, especially compared to Spacewalk (which I want to like, I really do).

feld 12y ago
That's on the roadmap. Eventually pkg will auto build only what is necessary to update your custom packages from ports when you do a "pkg upgrade".

aerique 12y ago

I've been using "dselect" for 15+ years on Debian now :-) But it is not simplistic.

glandium 12y ago

"Am I using dpkg here? What about aptitude? Or should I just roll w/ apt-get?" Just use "apt". It's new to Jessie, though.

weland 12y ago

Do you know of a non-broken way to build ports with many dependencies? This has always been my biggest annoyance and one of the things that constantly made me pick the cough other BSD. Whenever something that I need isn't in the package set, all hell breaks loose: most ports seem to have most options turned on by default (generating a lot of dependencies) and there seems to be no easy way to select configuration options prior to starting the whole build process -- so I end up having to sit for the next two hours, pampering the build process and tuning (actually, mostly disabling) options every time it moves on to the next port. Needless to say, this isn't fun, especially since there's no easy way to tell what dependencies an option is going to pull (I remember being able to retrieve that information through a script I cobbled up but...). I could probably script it to just go ahead with the default dependencies, but that gives terrible results (I try to install this little console tool and now it's pulling gnome-something-something because the console tool can be integrated with ImageMagick and that's compiled with support for this-weird-format which is provided by this-weird-lib which is part of the Gnome project and now I'm slowly compiling half the packages in Gnome even though I don't use a single program from the Gnome project).

rvanlaar 12y ago
You could run: make config-recursive a couple of times to do the configuration up front. See also: https://www.freebsd.org/doc/handbook/ports-using.html https://www.freebsd.org/doc/handbook/ports-using.html
- weland 12y ago
  It's what I usually do, but it's still annoying as hell when more than a dozen packages are involved in the build chain :(.
Freaky 12y ago
Add OPTIONS_UNSET=gnome to /etc/make.conf, plus whatever other options you want excluded system-wide. Ditto OPTIONS_SET. You can override for specific ports with ${PORTNAME}_SET/_UNSET too.