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)
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. "
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.
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.
"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.
"I think you've both missed the boat on this one. Development of a Linux kernel vs. the BSD system is different"
No, I bet *you* missed my boat. I was not talking about Linux kernel but about *Linux systems*.
"Theo et. al. have complete control of the kernel all the way down to the user-land"
Yes, they have.
"In Linux, however, userland tools are GNU"
No, they aren't. Not to the point of interest here. They are open source released under the GPL, hence Debian people (to name one *Linux system*) have exactly the same control level about their code than Theo et al. about theirs. No more, no less.
"The effect is that it is more likely you will see a shipped distro with broken tools due to the constant changes"
That strongly depends on the distribution itself. Linux distributions are free to put together a half-assed bunch of packages from different sources OR follow whatever process to insure the quality of their "official" releases, including extensive modifications from the "upstream" codebase exactly the same *BSDs are.
"making it very difficult to maintain a system with both kernels."
Thus, some decided to support both of them and others only one branch.
"Theo [...] describes refactoring as doable "when necessary [...] The Linux quote, OTOH, describes constant refactoring as a nuisance and a hindrance to Linux stability."
So? Theo refactors when he feels it is needed. Any given distribution refactors when feels it is needed.
Still I can't manage to see any *real* difference (yes I know what BSD folks *feel* to be the diference, cathedral vs bazaar, and all that stuff, but still, except from the preference for BSD-like licenses vs GPL ones, I can't see any procedural difference between any given BSD project and any given Linux one: in both cases we are talking about open source and in both cases the teams involved are in absolute control about what does go in their "official" codebase and what doesn't).
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.