💾 Archived View for gemini.circumlunar.space › users › kraileth › neunix › eerie › 2018 › ravenports… captured on 2021-12-05 at 23:47:19. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Here I'm republishing an old blog post of mine originally from July 2018. The article has been slightly improved.
Eventually when John stepped down from Dports he did find volunteers to hand to project over to. As of May 2021 DragonFly BSD still uses dports and has even imported _dsynth_ - a re-implementation of Synth written in C by Matthew Dillon - into the base system. While Raven is doing well (both Firefox and Rust as well as TeXlive were made available for example), it doesn't look like it's going to replace dports on DragonFly soon.
This is part three of a series of posts on cross-platform package management. The previous posts contained general thoughts about software packaging today and a somewhat in-depth overview on the Ravenports package system.
Modern-day package requirements
Ravenports: A modern, cross-platform package solution
In this post I want to give some more background on why Ravenports might be interesting to some people and explain the Dragonfly case. I'll also give you a little status update.
As mentioned in the previous post, Ravenports currently supports _DragonflyBSD_, _FreeBSD-amd64_, _Linux-glibc-x86_64_ and _Solaris / illumos on amd64_.
There are of course minor differences between the platforms: The _shadow_ package is only available on Linux because the other systems use different ways for scrambling user passwords, there's no _fuse_ for Dragonfly because that is not supported there and _iocage_ is FreeBSD-only because it's a userland jail manager. Also some packages don't build on the SunOS platform, yet, because they need additional patches. When I wrote my previous post, e.g. the xorg-server package was not available for SunOS. It _is_ now, though it's not of too much use, because the Xorg drivers aren't. Still you can see things are moving in the right direction.
Other than those special cases, Raven is consistent across all supported platforms (which is one of the major features that caught my attention after all): You can get packages of the _same version_ on Linux and FreeBSD (and the other platforms) and - as much as feasible - they are also _configured alike_. It's not guaranteed that the official repositories hold the same package versions at all times. If you require that, you currently have to roll your own repos but that's not hard to do at all (I'll write about actually using Raven in detail in a future post).
As I'm working in a heterogeneous environment, it is my hope that Raven will take a lot of the headaches away that result from native package management in the _Linux jungle_ (Ubuntu has one version, Debian ships another, CentOS is stuck with an ancient one and patches is to use a different directory structure, ... you get the point) and as a bonus offers the same version on *BSD. I'm pretty sure that I'm not alone in this jungle and while most of us are able to survive there, few would deny that it does require a big machete and some teeth grinding from time to time. It's ok - but can't we use our time for better things? I think so.
At home I'm more or less exclusively a FreeBSD user and that's the platform that I do my porting work on. I have in fact never seriously run Dragonfly - not actually because of a lack of interest in it but rather due to a very limited set of hardware available to me. I've never found a spare piece of hardware among my pool that would run the OS well. Still I'm dedicating most of this post to DragonflyBSD. Why? Because Raven is in a special position there.
As you may know, DragonFly BSD is by far the smallest of the four "big" BSD projects (some actually talk about only three and leave out dfly). They are doing an amazing job for the little manpower that they have, but all small projects struggle to keep up with changes going on in the open source ecosystem. Run your desktop on a *nix machine? Simply ask your package manager how many packages you have installed to make that possible and get a rough idea on just how much work needs to be put into maintaining all of them.
Most OSes and distributions maintain their own source repositories. Dragonfly never had the manpower to even consider this (also they have way different focus than just doing again what everybody else does). Historically this is why they used _Pkgsrc_ as this portable package system looked like a great option for DragonFly. A lot of work was put into it, but there were quite some issues with it.
Some were of technical nature: Pkgsrc can do binary packages, but if you know other package managers, the old tools really pale in comparison. There were conflicts in the release model, as Pkgsrc's quarterly releases were not well fit for dfly. But most importantly: A lot of packages were really outdated and where updates did occur so did breakage.
Updates were only tested against NetBSD and so it happened quite often that a single update broke anything from a couple to thousands (!) of ports for DragonFly BSD. Not even in the latter case would Pkgsrc suggest to revert the update that caused so much trouble - DragonFly was expected to fix all of the fallout themselves. To be fair, there surely was no intention to break anything. But there simply weren't any test farms either, so even if porters would have liked to care better for dfly, it wouldn't have been easy for them.
For technical problems there's usually a solution, especially if people are involved who both are knowledgeable on the topic and show great dedication. What's difficult to solve however, are _political_ problems. And that's what arose in the relationship between DragonFly and Pkgsrc: DragonFly BSD has officially been a first-class citizen and thus on-par with NetBSD. But because of the frequent breakage, DragonFly users felt differently about it. Unfortunately, multiple attempts and suggestions made to improve the situation also led to nothing.
In the end it became clear that Pkgsrc first and foremost is NetBSD's package system. Since one of NetBSD's primary goals is portability, Pkgsrc is of course also portable. This portability comes at a price, though - and that price is the need for a whole army of Pkgsrc maintainers to support an OS besides NetBSD well. As Pkgsrc was chosen due to the lack of manpower, this fact learned the hard way, showed that it wasn't the right solution.
Searching for a different one, John Marino stepped forward in creating an alternative: Dports.
In a nutshell this meant bringing FreeBSD's new package manager (pkg a.k.a. "pkg-ng") to DragonFly as well as FreeBSD's ports - with the changes necessary to make those build on this platform. It was a huge task but the advantages over the old system were big enough for the project to make sense. Eventually DragonFly BSD ditched Pkgsrc after more than half a decade and adopted Dports. If you want to know more, you can e.g. read the old comments here:
Of course Dports is not a "do once" effort; it constantly requires work to keep all the ports in sync with newer versions in FreeBSD's ports collection where the active development takes place. And John didn't have enough, he continued to experiment with packaging, writing _Synth_. He didn't like some of the aspects of FreeBSD's ports collection and on the other hand wanted features that were unlikely to find their way into the FPC.
Then FreeBSD introduced flavored ports. According to John, Dports had in general been less work for more packages available in comparison to Pkgsrc. However breakage still is an issue. And since the flavor-related changes in FreeBSD this has become much worse. So over time things have become more pressing for a real and permanent solution.
John had been thinking about new ways of package creation for a long time. With Synth he now had his own package building system and with package numbers increasing far beyond the point of somewhat acceptable maintainance requirements, he decided to give a new project a try after all and this evolved into what is Ravenports today.
Currently John Marino is working on Ravenports while still keeping Dports up to date. Last month he announced that he'd like to step down from working on Dports because he considers his time better spend on Raven.
Announcement about discontinuing work on Dports
The big question is now: Will somebody volunteer to claim maintainership for Dports? So far it doesn't look like it. Which means: After more than 5 years in existence, _Dports might actually go away_. Ravenports might replace it as the official packaging system on DragonFly BSD.
For that reason John has asked the community what packages are important for people. Again, I'm not a DragonFly user, but I've been very surprised by the response of the community - or rather the lack of it. Only a few people have responded so far and this makes me wonder if the majority of DragonFly users have either missed this totally or didn't realize what it means.
I'm convinced that Ravenports definitely is the superior system. However a transition would have a huge impact. When DragonFly switched from Pkgsrc to Dports it meant that a whole lot more package were available. In case of a possible switch to Ravenports the _opposite_ would happen: There's roughly *30,500* packages in Dports currently while at the moment the DragonFly repository of Ravenports holds exactly *3,600* packages!
Yes, the numbers cannot be compared 1:1, but it's not too hard to see that it would mean a dramatic decrease in packages being available. On the plus side, software versions in Ravenports are often much newer than the same program available on FreeBSD. More and more packages will be added to Raven - but this takes time. For that reason it's very important that you _tell us what software you depend on_ so that it can be added with higher priority.
Some packages have already been identified to be a problem. An important one is Firefox. Ravenports has it available in the latest ESR version that doesn't require Rust. But web browsers don't age very well and newer versions of Firefox are practically a must-have. Rust cannot be easily added, however - it's another problematic package. A third example is everything TeX which is a beast of a project.
One user requested more components of the Xfce desktop. I had started porting Xfce for my previous article anyway and I'm planning to either port the complete desktop or at least the most important parts. Next is _Thunar_, Xfce's file manager. But to give you an idea of what this means: Before I can even think about porting it, I need to get in a whole lot of dependencies first. A quick look at it showed that I might have to create up to 30 ports for that (including some that probably won't be trivial). So that's not work for one or two weeks but instead will likely take a lot longer.
Also I'm doing some work on getting FreeBSD-i386 working. It's in fact mostly done; I have some changed ports that I need to commit and one last package doesn't work to publish an i386 repo that is self-hosting. However this is more or less a thing that I'm doing for fun and to learn.
If I succeed with that, I plan on backporting Raven to FreeBSD 10 (amd64) and then 9. The reason for that is that I hope to make it run on _MidnightBSD_. It is a fork of FreeBSD and technically close to 9. As another (even smaller) BSD it also has the known problems in keeping up with all current package versions in their _mports_. So it could make sense to join efforts. But this is just an idea, I haven't approached Lucas Holt, yet, and I won't do so before I have something to show off.
Another platform that will likely be supported, is MacOS, further backing Ravenport's promise of being a universal package system. And Linux support will be improved in the future as well. Currently distributions that ship very old versions of glibc (e.g. Red Hat) cannot use Raven's packages. Possible solutions to that are being discussed.
Are you running a *nix operating system supported by Ravenports? In that case you can help. Do the bootstrap and start using it - it'll install to /raven by default so there should be no conflicts with your other package system. If you're using it, please provide feedback and create issues if you find problems! The more people actually use the packages, the more confident we can all be that those work well on all platforms.
If you have a little more interest in packaging systems, you can try to create a port and see if you like it. It does help if you're familiar with FreeBSD's ports, Dports or really any other package system, but that's not a requirement. I started with practically no prior knowledge and now after less than a year, I'm maintaining over 80 ports. I'm not a programmer and don't know much about _make_ and such. For me it has been a great learning experience.
Oh, and if I can do it, so can you. I intend to write another post on using Raven and at least one more about writing your own ports. If you want to give it a try before, feel free to contact me, I'll try to help. Also any questions are appreciated so I get a better idea if what I should write about.