Slashdot Mirror
OpenBSD Ports and Packages Explained
jpkunst writes "As reported on undeadly.org: an interesting interview with OpenBSD developer Marc Espie about the internals of and the philosophy behind the OpenBSD ports and packages system."
← Back to Stories (view on slashdot.org)
I'm in love with ports. It just makes things so damned easy.
I'd venture to say that without ports on FreeBSD, I'd never have learned so much.
I've always thought that with a little more polishing, it could be good enough for even my mom to use.
Pretty Pictures!
wtf are you on about ?
they are source code because they need to support 11 architectures and you might want different options to the pre-compiled binaries
nearly *all* the ports have binary packages for your particular source port, if you stick with GENERIC make options
you can even install them from ftp !
# ftp -a ftp.openbsd.org
ftp> cd pub/OpenBSD/$version/packages/$arch
ftp> get gcc-3.3.2.tgz "|pkg_add"
Personally I prefer OpenBSDs ports to FreeBSDs because OpenBSD will create the binary as a package so you can compile with your options once and install the package on different machines without re-compiling on each box
even better is that *some* of the optional parts also have pre-compiled packages
I was rather pleased to find the rc shell pre-compiled with readline support
# ftp -a ftp.openbsd.org
ftp> cd pub/OpenBSD/$version/packages/$arch
ftp> get rc-1.6-readline.tgz "|pkg_add"
how does that makes me a whacko ?
HIBT ?
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
FreeBSD will be glad to make you a binary package when you build a port, just type "make package".
"To those who are overly cautious, everything is impossible. "
OpenBSD does package first then install. FreeBSD does install first then package. The former method is useful when you want to build a package on a faster machine that will not be using the package. For example, building Apache on one machine for another slower machine when the fatser machine will never use Apache. The process using FreeBSD on the faster machine is build, install, package, deinstall.
OpenBSD's ports system is geared primarilly towards being a packaging system for the OpenBSD developers where FreeBSD's is more towards a general purpose installation, management, and packing framework. My personal wish is that FreeBSD would move to a portstree structure and management more like OpenBSD's.
There's a lot of very intelligent people working BSD. I'm a Linux zealot myself, but I really enjoyed reading this interview with Theo de Raadt, and Christos Zoulas. It's very interesting how much they seem to different in what they believe. One of the more striking ones was:
-vs-
It's hard to imagine that they are even talking about the same things.
Like some
I've been very happy with several concepts:
- The dependency trees are spot-on and very automated. Correct versions and complete coverage.
- The ability to undo or rollback a package is smooth (like when I took a 7.x Postgres package and pkg_delete'd it to try the port)
- The published docs, man pages and organization of the system is superb. I picked up "Absolute OpenBSD" and "BSD Hacks" and have been toured confidently around the system by these and the man pages they point to.
- The post-install notes are a great help.
For me, it's a great "warm and fuzzy" to gather the documentation sources into a list and be able to dive down rabbit holes for long periods without feeling like a flea market is on my box. Cheers to the BSD folks, especially the package maintainers.
OpenBSD installs into a "fake root" (you need root privs for this), and makes a package based upon this.
Not a troll, but sure... mod me down if you think so. (Just wait until someone answered, plz! :-)
Karma: Excellent (My Karma? I wish...:-( )
I hate having to have install Perl, Ruby and Python (m4?) for all kinds of trivial stuff. (or have it in the base systems as more and more systems do).
First, these scripting languages are slow. People that don't agree, please compile X, and watch the font making in Perl. It eats more time than actually compiling X
Second, every stupid package uses another one, so you end up with a bunch of them.
Third, it requires more languages to learn to access the system. Moreover, the amount of languages that can interface to Perl modules is significantly lower than the amount that can interface to C (virtually all). This can also be seen in the article: the perl backend is unused, everybody works around in shellscript.
The first two could be solved by e.g. limiting the tools to a perl subset that is compilable to C, and not use too many modules.
The third is harder to solve. Best would be to code the package system in C, and have a C callable library. Or maybe using 2C kind of stuff.
I think you've both missed the boat on this one. Development of a Linux kernel vs. the BSD system is different in exactly those regards which I've emphasized in italics.
Theo et. al. have complete control of the kernel all the way down to the user-land. In Linux, however, userland tools are GNU (hence the rage over Linux and GNU/Linux naming) and maintained closely, but separately. That means changes have to be rippled rather than made at once, atomically.
The effect is that it is more likely you will see a shipped distro with broken tools due to the constant changes, or that you can become inconsistent with kernel version and tool version. In the recent 2.4 -> 2.6 changeover there were several kernel/user tool packages that changed drastically, making it very difficult to maintain a system with both kernels.
Also, don't be fooled by the word "refactoring." A refactoring is a change of interface or architecture, and by definition breaks an interface contract - whether that is a public or private contract only influences the scope of the breakage. Theo talks a lot about making and rolling out comprehensive fixes quickly, and describes refactoring as doable "when necessary." The Linux quote, OTOH, describes constant refactoring as a nuisance and a hindrance to Linux stability.
I believe this is the point the OP may be trying to make with these two quotes.
"Theo et. al. have complete control of the kernel all the way down to the user-land. In Linux, however, userland tools are GNU"
I am aware of that. To a point. BSD machines, very often contain a lot of GNU software as well in userland.
"A refactoring is a change of interface or architecture, and by definition breaks an interface contract"
And 'stable' is not subject to sudden or extreme change or fluctuation and consistently dependable. When Theo says 'We can change interfaces as we want to. We can move quickly', he's saying it is a good thing that they can do exactly what Christos is accusing Linux of doing.
Theo is saying that if they change the kernel interface, then they can change libc as well basically. When Linux changes their API, glibc changes as well. The fact that it's one group and not two intermingled groups (RedHat maintains glibc, and is a Linux distributor, and contributor for example), doesn't mean much as far as stability is concerned. The difference is mostly political as far as I'm concerned.
having used apt-get and ports extensively, yes. The various BSD ports are better than apt-get. However, pacman (in arch linux) beats them all to hell. Simple, clean, and elegant.