As the year comes to an end, I’ve seen quite some interest in my previous post. There has been a question on Reddit what the benefit(s) of Raven over Pkgsrc might be and why the developers don’t simply join an existing effort instead of building something new.
I’ve touched on this topic about half a year ago, but I think the question is worth a detailed reply that fully covers both parts of it. So I’ll try to answer 1) why Ravenports exists in the first place and 2) what sets it apart from Pkgsrc and other ports systems.
Why maintain Ravenports instead of working on Pkgsrc?
Well, obviously because its author felt it was worthwhile to start and maintain the project! Of course that leads to another and more important question – why didn’t John Marino just join e.g. Pkgsrc instead? The answer to that is: Well… He did.
John got his NetBSD commit bit and became a Pkgsrc developer back in the day when DragonflyBSD still used Pkgsrc by default. He maintained a ton of ports there and made sure that other people’s ports still worked on DF after they had been updated. DragonflyBSD had been considered a first-class citizen by Pkgsrc. However there had been two big problems:
1) Being primarily a NetBSD project, Pkgsrc development takes place mostly on NetBSD of course. Things were tested on NetBSD and then committed. There was no testing done on the other supported platforms – which is a completely comprehensible decision given the amount of ports available and the number of supported platforms as well as the need to get software updated in a somewhat timely manner! However this lead to frequent breakage. A few suggestions that made sense from the Dragonfly perspective could not be agreed upon taking the whole of Pkgsrc into account. In the end the policy was: “If things in the tree break for your platform, go ahead and fix it.” So basically the answer to problem 1 was: “Throw more manpower at it.”
2) As the small project that DragonflyBSD is, there simply were not too many people available for this task however. In fact it was largely John alone who did most of the work with some help here and there. It’s impossible to spend resources that you don’t have available!
As you can see problem 1 causes problem 2 – and that one proved to be unfixable. Thus the problems with Pkgsrc grew and there was really not much that could have been done about it. And as the suggestions to somewhat relieve the worst impact were turned down, Dragonfly had to give up Pkgsrc. Please keep in mind that there’s a major difference between how Dragonfly used Pkgsrc and how some other platforms do. Sure, it’s great that you can use Pkgsrc on AIX to obtain some current software. Same thing for many other systems. Dragonfly used Pkgsrc just as NetBSD does, though: As the primary means to get software installed. Large-scale breakage of packages is a no-go in such a case, especially if it happens somewhat often and was bound to happen again and again.
Ok – another project then. Adapt the FPC maybe?
John then brought the new FreeBSD package manager as well as the FreeBSD ports collection over to Dragonfly with a system called “delta ports” or Dports. It’s basically an overlay with patches that Dfly requires to build those ports. Even though the FPC is meant for FreeBSD only and Pkgsrc – being cross-platform – might seem like the more logical candidate, this worked out a lot better and John maintained Dports for years.
In maintaining so many ports for both Pkgsrc and Dports he had a quite few ideas on how to do things better. They wouldn’t fit into the projects as they were organized, though. So he begun playing with various things on his own. Then… FreeBSD introduced flavored ports.
Don’t get me wrong here: I’m a FreeBSD user and I’m glad that flavored ports are finally available. However from a technical point of view they are implemented in a way that’s far from perfect. This is no wonder, though: When the ports tree was first introduced, nobody thought of flavors. What we have today is a fine example of a feature implemented as an afterthought. It works, yes, but it meant a disrupting change and broke expectations of all ports-related programs. It also made maintaining Dports much, much more time-intensive – to the point where it becomes no longer feasible to keep it up.
What does Ravenports have to offer over Pkgsrc?
Just like every younger project, Ravenports has the considerable advantage of starting fresh without the burden of choices that seemed right in the past but were probably regretted later. If this is combined with the will to learn from previous attempts to get packaging right as well as considerable experience with those, this has a lot of potential.
Think about it for a moment: FreeBSD’s ports collection shipped with the 1.0 release of the OS – and thus was created back in 1993. Pkgsrc began as a fork of it in 1997. So both were originally designed in a decade that has long passed (and in fact not even in this millennium!). Yes, both have been modernized over time. There are limits to this, however. It can be pretty hard to integrate new features into a structure that never meant to support anything like that. Do you think anybody in the mid 90’s could have thought about the needs of today? Ravenports deliberately does not support some old cruft. It’s meant for the coming decade of the 2020’s.
Here’s some strong points where Raven is ahead of Pkgsrc:
- Tooling:
- Pristine package builds:
- It’s fast:
- Potentially package manager agnostic:
- Powerful default package manager:
- Easy administration of multiple repos:
- Convenient use of custom ports:
- Variants and subpackages:
- Testing:
- Automation:
- Modern day development:
- No ports ownership:
- Fast releases:
- Binary bootstrap:
It offers a modern, integrated solution. There’s one control program (“ravenadm”) that deals with everything regarding Ravenports: It’s used to configure the package building system, it fetches the buildsheets (ports) and keeps them up to date, it builds all the packages or a subset thereof, …
Everything is built in a chroot sandbox specifically assembled for that build process. There is no way that build dependencies clutter your build system (chances are you don’t want to use m4 or automake yourself and thus don’t need them installed on the OS). There’s also no way that installed packages of your system pollute the packages that Raven builds: The isolation prevents e.g. linking against additional stuff that you didn’t mean to.
Did you ever run a bulk-build for Pkgsrc packages? Ravenports optimizes build times on modern systems by taking advantage of memory disks and such. The port scan alone makes a huge difference.
Currently Raven supports only the Pkg package manager but as all it does is build packages, it was designed to support additional package managers if needed. You actually want it to generate rpm or pacman packages? Not currently implemented but certainly possible if desired.
Pkg, a modern tool for package management, is quite capable. If you read the manpages for it you will find out that it’s loaded with useful features. The old pkg_tools that Pkgsrc still use totally pale in comparison – and rightfully so.
Need multiple repositories? No problem. Just create profiles for them. E.g. one that uses LibreSSL and another one that links against OpenSSL instead. Also you can choose the default version of Perl, Python, Ruby, ect. to use. And you can choose if MySQL should be Oracle’s MySQL, MariaDB, Galera, ect.
Can you use custom ports that are not in the official buildsheet collection? Sure thing. You can create directories for your custom ports and even use different ones in different profiles. Want to change an existing port? Just place one with the same name in your custom port directory and it will override the original one. Buildsheets from custom ports are generated automatically so there’s no hassle there. It probably doesn’t get much more convenient!
Package variants (i.e. “flavors”) and subpackages are not an afterthought and are thus used excessively right from the beginning. This makes package management with Raven very flexible.
The Ravenports system has very strict rules for buildsheets. If the ravenadm tool considers a port to be valid, it is almost guaranteed that it is actually fine. Also packages can not only be mass-built but they can also be tested automatically as well (Is the RPATH ok? Are all required shared objects available? Is the manifest file complete? Are the required descriptions in place? Is the license ok or lacking? Things like that).
Ravenports tries to automate many things that do not actually need human attention. For example quite often Python-related ports can be auto-generated. This saves time and effort of the maintainers that can be better spent on other things.
Want to contribute something? It’s extremely easy. If you have a GitHub account you’re all set: Fork the git repo, make your changes, then commit and push them. Now all that’s left is opening a Pull Request. Yes, that’s all. If you don’t have a GH account, create one. Or send us patches as it was traditionally done. Ravenadm will happily create a template for you to assist you if you want to contribute a new port.
In Ravenports nobody “owns” a port. If you submitted one you become a contact for it. If somebody wants to make major changes to the port, that person is expected to contact you and communicate the proposals. Small or trivial changes however (like a simple version upgrade) can be done by anybody. This ensures rapid development and very fast adoption of new versions even if the original porter does not currently have the time to maintain everything in a timely manner.
Ravensource provides new releases quite often. This way you can get pretty fresh software early on. There is no fixed time frame for it, though: Releases are made when it makes sense. If there have been major changes to the tree the next release might be delayed for testing.
Ravenports has a very simple and fast bootstrap process that makes use of binary packages for the respective platform. No system compiler required! Raven brings in its own full toolchain.
There are of course cases where it makes sense to use Pkgsrc and it’s not too hard to find any: E.g. if you need packages for a platform that’s unsupported in Raven or if you need software not yet available there. In the end this is Open Source: We’re all friends and using the right tool for the job makes sense.
Couldn’t Ports/Pkgsrc be modernized?
I’ve used Pkgsrc both in private and at work and I’m pretty happy that it’s available when I need it. But I don’t like the old pkg_tools much. They do their job but they are far from modern programs and really feel like relics today. And while I’m pretty happy with FreeBSD’s ports, those aren’t portable (and for some reason I’ve never been completely happy with Poudriere, FreeBSD’s package builder).
Before finally creating Ravenports, John wrote Synth, a very nice package builder for FreeBSD and DragonflyBSD that supports Ports/Dports. It has been put on hold in favor of Raven, but it is still maintained and I continue to use it on FreeBSD to build my packages.
John also created Pkgsrc-synth. It’s a version of Pkgsrc that uses the Pkg package manager. I’ve never tried it out – but it was stopped exactly two month ago as there seems to not have been any interest from the Pkgsrc people. I think this is a pitty, as pkg is really nice and has the right license for any BSD project. It could have been a chance to move Pkgsrc into a more modern direction. But meh.
Conclusion
Raven does not exist because everything else sucks. It exists because all the other candidates proved to not quite fit the needs of Ravenport’s author. As such it is a chance to keep the good parts of its various precursors that it heavily draws inspiration from. It’s a chance to combine these good parts to make something awesome. And it’s a chance to implement a lot of new ideas that should make sense in modern-day *nix package building which – for various reasons – cannot have a place in the old projects.
There’s still a lot of work to do, but we’re getting there. In my previous post I wrote that one of the big shortcomings was the lack of Rust. In the meantime Rust support has landed for DragonflyBSD, FreeBSD and Linux.
If there are any more questions feel free to post them here. I’m not on Reddit and I just saw the above question by accident. So I cannot promise to answer anywhere else than here.
Happy new year everyone!
eerielinux 
One thought on “Ravenports explained: Why not just join XYZ?”