Slashdot Mirror
Unified BSD packaging system?
Chris Coleman is putting his money where his mouth is, after his recent suggestion that the BSDs need a unified package collection. The creation of www.openpackages.org was the next logical step, and Chris discusses this in his latest Daemon News editorial. With representatives from the three free BSD projects, as well as Apple (MacOS X) on board, this certainly has the potential to bring about closer ties between the BSD distributions at a level that will affect a lot of users.
How will all the BSDs choose an appropriate lisence for the packaging programs though? Seems like since each BSD has a different license they will all want the package system to be in their own native license, or have I been using Debian too long?
.deb with a simpler style?
Still this is an interesting concept, especially since not everyone can write portable code, and porting can then be done by one person and distributed as packages (I ran into this problem trying to get Mozilla to run on Irix, just reading the process turned me off)
I also wonder what packaging systems it wil be based off of; will it be like RPM with lots of functionality but confusing or absent categorization (my RPM databases always turned into one package per category because I'd install mandrake or SuSE packages on top of RedHat), or will it be like
# debian/rules
It looks like there will be a single ports tree from which binaries for any of the BSDs can be built easily. (For those of you who don't know, ports are an automated way of downloading, compiling, and installing software).
I imagine that this will be a huge benefit to users of things like OpenBSD, which has 400-500 ports (I think), in comparison to FreeBSD's several thousand. Each of the free BSD's already have their own binary package system (which is basically the same), but their port systems are in very different states. This will be a huge boost to BSD, and make it even easier. I hope it succeeds.
-- Floyd
-- Floyd
A few posters here don't get it. The ports-collection (package for NetBSD) has nothing (or at least almost nothing) to do with .deb .tar or .rar. It is a system to install programs on your system. So before you shout "Yet another incompatible packging-system" try to understand, that it's the opposite case here. It tries to bring three (four with Darwin) Systems together. And I hope that this project will suceed.
I started my journey into the world of Unix OS's with RH 6.0, then upgrading to 6.1. The first couple of rpm's I dealt with really impressed me with how it handled stuff. Then, as many have mentioned, I started running into the enevitable dependency problems. Especially true with Gnome based apps. As time wore on I also noticed that it was becoming increasingly difficult to locate the latest version of an app as an rpm. The GUI rpm tools that were supposed to go hunt down the latest stuff off the web consistantly pulled back far older versions, and often pointed to dead web and FTP resources. I always loved running into the RedHat FTP server in a 24/7 overloaded state. So here I was manually compiling and install stuff outside the rpm database. Completely defeating the purpose of having package management.
One hard drive crash later I decided I'd try out a different distro. After a couple of days mulling it over I decided instead to try out FreeBSD. After figuring out how to pull down the latest ports package I tried running a couple of them. I can't begin to express how impressed I was with this. It appears to consistantly have the very latest stuff, it deals with the compilation and installation for me, and enters the app into the package management system. That, and as I watched it poll a list of ftp sites looking for an active one, then also went about pulling in required libraries my jaw just dropped.
As impressed as I am with how FreeBSD handles apps, there is one aspect I fealt wasn't quite as strong as rpm. rpm's provide a fairly elegant method of udgrading applications that appears to deal with the issues of cleaning out the old app and getting the new one in there. FBSD on the other hand has you go with a process of deinstalling then reinstalling which seems to be prone to all kinds of nasties.
For example, when trying to deinstall a library that other apps depend on the system will stop ya in your tracks. Just trying to install over an older app puts both versions into the database. I'm still fighting a wrong turn I made when upgrading XFree86. I'm certain that a more experienced user would have danced right around the probs I had, but it seems evident that there is room for improvement here.
As it is, I'm far happier with the dealing with apps on FreeBSD than I ever was with RedHat. I genuinely hope that this new project can help better streamline this process. Furthermore, it seems that the various Linux distros could greatly benefit from something like this as well.
The line must be drawn here. This far. No further.
But is it the very same ports tree for all 3 BSDs?
.deb packages. Too large of an installed base for both to just change gears now, and there's also a point of pride that kicks in as well. If anything, I expect the various Linux distros will most likely just hunker down further in however they handle package management.
Nope. That's the reason for starting up the Open Packages project in the first place.
And what would it take to integrate Linux
Hopefully I don't screw up this description here. On FreeBSD there are two different methods for adding packages. The first is from the "ports" collection. These ports are a collection of fancy makefile scripts that have a series of expected locations of the source files, and some instructions on what to do with them, ie. configure, compile, install. These scripts also include a list of dependant packages which are used to either verify they exist, or go and install them.
The second method of installing an app is doing a pkg_add, which is a method for dealing with already compiled packages.
The only stumbling block I would think that a Linux distro would have in implementing this is the final stage of a port install: entering the package into the database. For instance, on RedHat it's expected that all apps will get an entry into the RPM database. FreeBSD sort of expects the same thing, only to it's package db instead. The concept of package management breaks down real quick like when more than one db is in use, since that is what is referred to for tracking dependencies and such.
The really sad part here is that even if this Open Packages project ends up making folks wonder what was so great about sliced bread anyway, it still won't get used on Linux. RedHat isn't showing any signs of giving up on rpm's, and the same can be said for Debian's
The line must be drawn here. This far. No further.