Slashdot Mirror
DragonFly BSD 3.4 Released, With New Packaging System
An anonymous reader writes "DragonFly BSD has released version 3.4. This version is the first BSD to support GCC 4.7, and contains a new experimental Aptitude-like binary package installed called DPorts, which uses the FreeBSD ports collection as a base."
The regular package management for BSDs, the ports collection, is not like .rpm or .deb at all. The closest Linux equivilent would be Gentoo, since it was based on Ports, and improved upon from there (improved in the opinion of the people doing the improving anyway.) Everything there is compiled from source based on some pretty beefy makefiles.
I don't know much about this new package system, but if it's based on Aptitude, it's probably better to compare it to apt-get or Yum than to .rpm and .deb.
One big difference between *BSD and most Linux systems is that a *BSD system consists of a base system plus packages. With a lot of the Linux systems, the whole system consists of packages. So for example, with a Debian system, your kernel is managed with apt thus it is managed with a package manager. In *BSD, the kernel is part of the base system.
Wikipedia has a rather well written article on FreeBSD's ports system (and being that FreeBSD has the largest user base of the *BSDs, it is often thought of as "the BSD system"). http://en.wikipedia.org/wiki/FreeBSD_Ports
Additionally, it may be worth noting that FreeBSD is transitioning over to a new binary package system called "pkgng", (to replace pkg_add, not ports). I don't personally know much about it, but the trusty old FreeBSD handbook has a section on it: http://www.freebsd.org/doc/en/books/handbook/pkgng-intro.html
They have some nice ideas. The one that particularly interests me is settings up a bunch of DragonFlyBSD servers and having jobs run transparently across them, load-balancing across the cluster. This is like multi-core at the server level -- the same kind of underlying abstractions as well. Not sure if they've got it up and running yet.
FreeBSD has had packages for years. It's not transitioning, it's allowing another option.
Ports in FreeBSD, in my experience, if you follow a production-like attitude, rather than an ADD OH-NOEZ-THIS-PORT-IS-30-SECONDS-OUT-OF-DATE-MUST-UPDATE methodology, works better than any package manager I've seen (rpm, deb, yum, apt).
The BSD package systems tend to be more like apt or yum, than simple rpm/deb. They grab your binary packages and their dependencies automatically.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
You missed the entire point. In BSD the kernel is not itself a package. In linux the kernel is a package just like any other package. THAT's why he is informative.
It's actually more like, but imagine apt-build out on the front of the interface. In the newest FreeBSD pkg-ng, there are no binary packages other than a few that are able to be used for bootstrapping pkg-ng, so you are compelled to build them (with portmaster or manually mucking with makefiles in /usr/ports)
There is a "non-ng" pkg tools set, classic pkg_add pkg_delete pkg_info etc that has many packages that you can download (would it be accurate to say most of ports tree? I don't think so), but they are not generally kept up-to-date outside of releases and probably security updates. You are encouraged to use portmaster or another tool to keep your packages up to date.
The difference (at least in FreeBSD) is that you can't generally have current packages without building them (but all of the atomic guarantees about installing and removing packages you've come to expect from dpkg/apt-get are still there, to my knowledge).
In Debian there is always sid, or Ubuntu (next), where you can keep up to date just by downloading binary packages. I don't know how this dragonfly package system 'dports' compares to that.
Restating the obvious since nineteen aught five.
apt-build takes the sources and produces a deb that is then installed.
A parallel then. Ports downloads application sources, compiles and installs.
The only difference is one produces a package file before installing, I wouldn't say that's 'barely' different.
Change is certain; progress is not obligatory.
No, you're wrong. The kernel is in a package and you can upgrade it via apt-get [dist-]upgrade. In FreeBSD and ilk, you have to gather up /usr/src and make buildkernel to get a new kernel. Frequently you will also want make world, which compiles the rest of the base system (think GNU toolchain, but this is definitely not GNU) that are not in packages.
You can't really boot just a kernel without any child processes to positive effect (source?), so Linux is not the "base system" -- GNU/Linux is that. In BSD, that's 'world' and ports is everything not world or kernel.
Restating the obvious since nineteen aught five.
I don't think most people on Debian are rebuilding their systems using apt-build. Then again I'm not most people. My boss insists there's some reason to use aptitude but whenever I try to corner him, he tells me about the use case for dist-upgrade without naming dist-upgrade, and can't give other reasons.
"apt-get will leave packages in held state"
yeah, when there's a dependency that was not previously installed, you have to use dist-upgrade to insist that apt-get installs new packages, step that's not usually part of an upgrade.
I'm going out on a limb and guess that neither of us knew about apt-build.
Restating the obvious since nineteen aught five.
Freebsd and gentoo at least also have binary package systems.
Afaict the difference is that on BSD/gentoo building from source at install time is the primary method while installing binaries is an extra. On debian installing binary packages is the primary method while building from source at install time is an extra.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
I don't think most people would need to on any OS unless the OS forced them.
I have used apt-build on custom architectures (targeting a custom arch, like when I was building packages for my Nintendo DS) and for specific packages that needed extra features the package maintainer failed to provide (usually from a 3rd party repo rather than distro repos).
I don't know why you're telling me this.
Does this even matter since we know how to deal with this trivially?
Change is certain; progress is not obligatory.
In the FBSD family, there are the portsng, and then, there are the PC-BSD based PBI system. PBI is really good in that it checks for all version dependencies, and then frees up space by removing the genuinely redundant dependencies using a hash table. In fact, FreeBSD is being distributed on the same media in the same format, and even pFsense has adapted this PBI distribution.
I am surprised therefore that DragonFlyBSD didn't choose to go with this solution. On a different note, DragonFly is still on GCC? I'd have thunk that they'd be interested in LLVM/Clang or PCC or some such...
Ports are generally small scripts that retreive source and build a binary package that is then installed.
OpenBSD uses special Makefiles that do exactly this. The few binary packages provided are just those generated by these makefiles (only some are provided in binary form).
Archlinux uses PKGBUILDs which are quite similar (in nature, not in syntax) to BSD's ports. While arch uses binary repositories, building a package is just a matter of running makepkg with the correct PKGBUILD file.
Compared to rpm and deb? Most of the everyday features are there. I'm sure some of the less-common rpm/deb features are missing. Dependency management has existed for ages, of course.
The regular package management for BSDs, the ports collection
The regular package management for BSDs is the pkg utilities, the ports collection is a source control tree of available software that you compile yourself.
To be fair, only FreeBSD uses the Ports Collection, but also uses 'pkg' which fetches precompiled binaries and installs them and handles dependancies, which is pretty much exactly like apt and rpm. NetBSD and IIRC, OpenBSD both use pkgsrc, which also fetches binary packages, exactly like apt and rpm. All three have had this sort of package management forever.
Ports in FreeBSD, in my experience, if you follow a production-like attitude, rather than an ADD OH-NOEZ-THIS-PORT-IS-30-SECONDS-OUT-OF-DATE-MUST-UPDATE methodology, works better than any package manager I've seen (rpm, deb, yum, apt).
My only complaint about FreeBSD ports is that, somehow or another, everything you install wants to depend on X.
...followed by bisecting to see which port wants to install the perl-tk package so it can install a config tool you'd never actually run on a production server. It desperately needs a WITHOUT_X11_I_MEAN_IT_DAMMIT=yes option.
Dewey, what part of this looks like authorities should be involved?