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)
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
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.
A good reason for perl is that it *works*.
A second good reason is that it's already part of the OpenBSD base install.
A third good reason is that the old package system was in C, and was downright broken.
A fourth good reason is that the current perl system is over 200K of perl code. Try rewriting that in C, and see how big it gets.
Finally, maybe perl isn't that slow... I've rewritten all kind of C/shell code in perl, and it consistently is faster than the old C code. Why ? because I can use smarter algorithms, and better caching. The package system of OpenBSD is another example of the same. Dude, the perl version of pkg_add is about twice as fast as the old perl version.
As far as X font building goes, you can't really know if it's slow because perl is, or if it's slow because there's a large amount of stuff going on. Look at the sizes involved, look how much data is processed, realize that usually, everything gets compressed with gzip.
Now, you can think all you want that it's slow because perl is slow. Well, I've got at least two other reasons for it to be slow.
What you have is an opinion, and not really well informed. How about backing it with some actual facts ?
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.