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
If this could become a reality (meaning that a package is a package is a package, on all BSDs) it would also make life much easier for those admins who need to work heterogenous environments.
The concept of bringing OpenBSD's security scrutiny to the BSD community at large appeals to me. In fact, this could concievably be a rather powerful tool in the battle for Open Source:
Basically the idea is to create some sort of standards body / code review group, operating independently of any one (free) OS but ideally with input (at least a person or two) from each OS community. This group would check code against portability criteria, stylistic standards, security checks, etc. Heck, you could even have submitted code ranked in these areas.
Once examined, the (formally, legally) Open Sourced code could be put into this central repository (hint: here's the connection to the UniPort thing the post is talking about) and packaged in such a way for standards bodies (maybe an interoperability group, for example) to examine them, ports groups to package them, yada, yada.
This is a rather rough-hewn idea; got any suggestions for it?
Oh yah, to mail me.... sed -e 's/sp.*am\.//g'
cat email | sed -e 's/sp.*am\.//g'
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 understand the general idea is with binary packages, which is fine and dandy but my question is WHY? Binary packages kind of suck, IMHO -- so many things have build-time configuration options that I've never seen documented worth a damn in other binary package formats (like RPM, for example). Then there's the library go-round, especially on Linux, that makes Windows
Binary packages? No thanks, ports is just fine for me.
A unified BSD ports/packaging system is definitely a good and logical step forward. Despite the differences in focus of each BSD flavor, I believe that a unified ports tree will stop a lot of duplication of work. If this goes down, we BSD people should hope to see more ported apps with less failed builds.
One thing I must mention, though -- and since all I know about is Free BSD, this might not be true for the other BSD distros. There need to be both source and binary packages available, and there needs to be only a MINIMUM amount of disparity between the two. Currenly, there is too big of a difference in what you can get with the ports tree (source) and the packages collection (binaries). The way applications are named and organized is different in either place, and the selection differs, too. Any unified ports tree needs to make it simple to choose whether you want to build from sources or just install binaries -- and offer both choices for each app unless licensing issues would prevent it.
Being a programmer, I prefer to build most of my third-party apps from source. However, I might not want to wait for some of the bigger ports (kde2, for instance) to build. Installing binaries should be equally accessible.
Washington, DC: It's like Hollywood for ugly people.
Why binary... slow machines!
For many years my only box was a 75Mhz pentium. Compiling anything took forever on this box so... binary packages were good.
Also... with something as intelligent as the Debian packaging system, I don't need to worry about dependencies and compiling every little thing that package foo needs. One good example is GNOME or KDE. I actually have things that I need to get done other than watch my machine compile a desktop environment all day.
I have nothing against compiling from source, and I do really like the FreeBSD ports. I also like typing apt-get source foo then running dpkg-buildpackge and having a .deb with all the dependencies in tact.
This is no big deal, as this is very likely the case already for the differing versions for the differing BSD variations.
Note that there are Ports for all sorts of GPLed software and such.
The point here is that what licensing is crucial is that of the package tool, and not anything more than that.
By the way, it is eminently likely, and should be blatantly obvious to anyone that does a modicum of research that the system proposed is to be based on the BSD Ports system, which is neither particularly like RPM nor is it greatly like dpkg. (Although the differences betwixt Ports and dpkg are a bit less dramatic, as the Debian project has a similar interest in having "somewhat centralized public access to the source code tree."
Ports involves a "central" Makefile that knows how to look up source code for individual packages. It is essentially based on the philosophy of pulling sources for software, wrapping around it a Makefile and any patches needed to resolve differences between pristine sources and the code that is needed to make it compile and run on the system in question.
If you're not part of the solution, you're part of the precipitate.
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.
One thing I don't like about the FreeBSD ports system is that you can install a package that conflicts with another package, sometimes without even knowing about it. For example, I installed kde 1.2 from ports a while back. Now I recently installed kde 2.0beta4 from ports. I had trouble getting kde2 to compile in the first place, so I didn't want to remove kde 1.2 . But now that both are installed, they both claim ownership to certain files. So now if I were to uninstall kde 1.2, it would delete kde2 files as well.
I see this happening a lot with library packages. You might have a previous version of gtk installed, for example. But then when you compile a new GNOME application, it'll trigger the compile and install of a new version of gtk. But the old one doesn't get uninstalled. It just installs on top of it. And then there's no way to clean out the old one after the fact. I end up deinstalling both, and reinstalling the new one. I think that at the very least, packages should all attempt to uninstall earlier versions before installing.
With FreeBSD ports, you can find out what files are part of an installed package. But you can't go the reverse direction. You can't ask what package a file belongs to. RPM can do this. I suppose that's how RPM prevents packages from clobbering each others files. And somehow RPM can do this without making the install process slow.
Redhat Linux's RPMization of everything does make things rigid. But there are some advantages. It's mostly easy to upgrade to newer versions of the distribution. Since the Redhat installation just consists of bunches of installed rpm's, you just need to upgrade every package. Once I had a Redhat 6.1 upgrade installer break on me. But all I had to do was do an "rpm -Uvh" on each of the rpms to upgrade from RH6.0 to RH6.1 .
But in FreeBSD, an upgrade install (or make world) just dumps stuff on top of whatever you already have. So shared libraries and programs from the earlier install get left around.