On FreeBSD and Debian package management
About a year ago I was contemplating writing a graphical package management tool for FreeBSD. I had been using bpm on and off for a while and while it was close enough to what I needed, the effort to extend it wore me off pretty soon. After all, how much GUI programming in plain C can a decent man endure?
Anyway, after picking a more workable solution on the programming language front, I had sketched up a GUI prototype and was considering the available options for the actual package updating code. My main interest was in binary packages and there were a few available command-line tools and libraries. None of the options seemed to work well enough though. Besides various communication issues among the two tiers of my application, what really drove me off this pet project was the source-based nature of the ports framework. That and the tiny issue of fatherhood, to be precise. I've tried to explain it once, but what I really wanted was something like the Debian system, which I'd argue is a better fit for regular users.
Michel Talon, long time FreeBSD user and developer, appears to have researched the issue more thoroughly while developing pkgupgrade, a tool that would have been another great option for my own project, had it been available last year. Pkgupgrade is written in Python, which would make it even yummier in my opinion. It's not Java, but it's close enough for my taste. Michel's comparison of the FreeBSD package system and the Debian one, comes to the conclusion that binary package management systems are inherently better for casual users than source-based ones:
"But the main factor ensuring reproducibility and reliability of the apt system is working with binary packages. You can be sure at least of the existence of a binary package, and probably that it works, due to the severe testing in the Debian system. There is no guarantee in a source based system. Hence no package management system can be reliable, however sophisticated it is."The above excerpt may sound a bit harsh, but if you read the whole paper you'll see that the author's arguments are pretty balanced. Now that I've had the chance to use Debian's apt system for a few months, I can say that I wholeheartedly agree with Michel. This is pretty much what I had in mind for FreeBSD last year and I still think this is the direction the project should follow.
The upside for FreeBSD is that I no longer have the time to work on my old Java-based graphical package management tool. Because, let's be honest here, a system tool in Java? How many rotten tomatoes would be coming my way?
2 comments:
Personally i think that a combination of pkg_* tools and portmaster (only for building custom packages with specific options) is the way to go. I got nothing against using a lil older packages built specifically for RELEASE version. That way the whole system is more reliable and stable. Building ports from the current CVS ports snapshot can often break things.
Agreed, this is what I usually do, too. But as you note, and Michel Talon eloquently explains, this is still not safe. There are occasional port updates that are meant to accommodate a larger port infrastructure update and not a new feature of the port itself, that will render this process broken as well.
For instance the soon-to-happen upgrade of the xorg ports to version 7.2 will probably necessitate updates to say the gnome ports. If you were using release packages plus a couple of custom ones for gnome, after the xorg merge you will probably be unable to keep up.
Granted, this is something that does not happen very often, but still, it should be possible to accomplish with your regular tools, instead of a special upgrade script.
Unless of course you meant using custom packages from the release ports tree. In other words you never update the ports tree between releases. That would definitely work, but since the ports tree is never branched you get port updates only when a new release comes out.
Post a Comment