💾 Archived View for gemini.circumlunar.space › users › kraileth › neunix › eerie › 2019 › rusted_rav… captured on 2024-08-18 at 19:34:20. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-05)
-=-=-=-=-=-=-
Here I'm republishing an old blog post of mine originally from March 2019. The article has been slightly improved.
It’s been a couple of months since I last wrote about Ravenports, the universal *nix application building framework. Not exactly being a slowly moving project, a lot has happened since then.
Ravenports: A modern, cross-platform package solution [2018]
Ravenports: Status update and the Dragonfly case [2018]
Ravenports explained: Why not just join XYZ? [2018]
Raven currently supports _DragonFly BSD_, _FreeBSD_, _Linux_ and _Solaris / illumos_, the latter being only in the form of binary packages (except for when you have access to an installation of _Solaris 10u8_ - which can be used to build packages, too).
People following the project will notice the lack of macOS / Darwin support mentioned here. This is not a mistake as support for that platform has been _put on hold for now_. While Raven has successfully been bootstrapped on macOS before, the developers have lost access to any capable macOS machines and thus cannot continue support for it.
This does not mean that platform is gone forever. It might be resurrected at a later point in time if given access to a Mac again. The adventurous can even try to _bootstrap Raven_ on different platforms now as the process has been documented (with macOS as the example).
Ravenports Platform Bootstrap documentation
I intended to do some work on bootstrapping Raven on FreeBSD/arm64 - only to find that FreeBSD unfortunately still has a long way before making that platform tier 1. At work I had access to server-class arm64 hardware, but current versions of FreeBSD have trouble booting up and I could not get the network running at all (if you're interested in the details see my previous post). I'm still hoping for reactions on the mailing list but until upstream FreeBSD is fixed on ThunderX trying to bootstrap does not make much sense.
ARM'd and dangerous: FreeBSD on Cavium ThunderX (aarch64)
The toolchain used by Ravenports has been updated to _GCC 8.3_ and _Binutils 2.32_ on all four supported platforms (access to Mac was lost before the toolchain update).
As usual, Solaris needed a bit of extra treatment but up to date compiler and tools are available for it now, too. Even better: The linker from the LLVM project (lld) is available and usable on Solaris / illumos now as well. Since it takes several hours (!) to link on Solaris, a mostly static lld executable was added to the sysroot package for that platform. This way this long-building package does not have to be rebuilt as often.
Packages have been rebuilt with this bleeding-edge toolchain (plus the usual fallout has been collected and fixed). So if you are using Raven, you are making use of the latest compiler technology with the best in optimization. Of course a lot of effort went into providing the most current versions of the packaged software, too (at least where that is feasible).
On the desktop side of things I've added the _awesome_ window manager to the list of available software. It's actually my WM of choice, but not too many people are into tiling so I postponed this one for after making Xfce available. Work on bringing in more Lua-related ports for an advanced configuration it is ongoing, but the WM is already usable as it is now.
I've also done a bit of less visible work, going back to many ports that I created previously and added in missing license info. This work is also not completed, yet, but the situation is improving, of course.
One of the big drawbacks of Ravenports as stated last time, was the lack of the Rust compiler. This effectively meant a showstopper for things like current versions of Firefox, Thunderbird, librsvg, etc. The great news is that this blocker has been mostly removed: Rust is available via Raven for DragonFly, FreeBSD and Linux! Solaris / illumos support is pending, I think that any helping hand would be greatly appreciated.
Bringing in Rust was a big project on its own. Adding an initial bootstrap package for DragonFly alone took months (thank you, Mr. Neumann!). The first working version of the port made Rust 1.31 available. It has since been updated to version 1.32 and 1.33 and John has added functionality to the Raven framework to work with Rust's crates as well as scripts to assist with future updates. Taking all of that into consideration, Rust support in Raven is already pretty good for the short time that we have it.
Eventually even a port for Firefox landed - as of now it's marked broken, though. The reason is that while it does compile just fine, the program crashes when actually started. The exact cause for this is yet unknown. If anybody with some debugging abilities has a little time on his hands, nailing down what happens would be a task that a lot of people will be benefit from for sure! [update: It works on DragonFly and Linux, I think, but I couldn't get it working on FreeBSD so far.]
Ravenadm, the Ravenports administration tool, has seen several updates with new features. Some have brought internal changes or new features necessary for new or updated packages. One example is a project-wide fix for ports that build with Meson: Before the change many programs needed special treatment to make Meson honor the _rpath_ for the resulting binaries. Now Raven can automatically take care of this, saving us a whole bunch of sed commands in the specification file. Another new feature is the "Solaris functions" mechanism which can automatically fix certain functions that required generating patches before. Certainly also very nice to have!
Probably my favorite new feature is that Ravenadm now supports concurrent processes in several cases: While you cannot start a second set of package builds at the same time for obvious reasons, it is now possible to ask Ravenadm in which bucket a certain port lives, sort manifests, and such while building packages! I cannot say how much the previous behavior got in my way while doing porting work... This makes porting much, much more pleasant.
A last improvement that I want to mention here is a rather simple one - however one that has a huge impact. Newer versions of Ravenadm put all license-related texts into the logs! This means you can simply look at the log and see if e.g. the terms got extracted correctly. Before you had to use the ENTERAFTER option to enter an interactive build session and look at the extracted file. This is a huge improvement for porters.
Another big and most likely unique feature added to Raven recently is SSL autoselection. Raven has had autoselection facilities for Python, Ruby and Perl for about a year now. The latter allow for multiple versions of the interpreters to be installed in parallel and take care of calling the actual binary with the same parameters, preferring the newest version over older ones (unless configured differently).
Raven supports LibreSSL, OpenSSL as well as LibreSSL-devel and OpenSSL-devel. Before the change, you could select the SSL library to use in the profile and it would be used to link all packages against it. Now we have even more flexibility: You can e.g. build all the packages against LibreSSL by default and just fall back to OpenSSL for the few packages that really require it!
And in fact Raven takes it all one step further: You can have OpenSSL 1.0.2 and OpenSSL 1.1.1 (which introduced braking changes) _installed in parallel_ and use packages on the same system where some require the new version and some that cannot use it, yet! Pretty nice, huh?
Of course there are still enough rough edges that require work. Probably the most pressing issue is to get Firefox working so Raven's users can have access to a convenient and modern browser. There are also quite some programs which need ports created for them. The goal here is to provide the most critical programs to allow DragonFly to make the switch from Dports to Ravenports for the official packages.
On FreeBSD Filezilla does not currently work: It cannot be built with GCC due to a compiler bug in GCC 7.x and 8.x. Therefore it is a special port that get's build with Clang instead. The problem is that libfilezilla needs to be built with the same toolchain - and that cannot currently be built with Clang using Raven...
Raven on Linux has some packages not available due to additional dependencies on that platform. I began adding some Linux-specific ports but lost motivation to do so pretty fast (there are enough other things after all). Also the package manager is still causing pain, randomly crashing.
Solaris is also missing quite some packages. This is due to additional patches being required for a lot of software to build properly. Ravenports tries to support this platform as good as possible; however this could surely be improved if anybody using Solaris or an illumos distribution as his or her OS of choice would start using Raven and giving feedback or even contribute.
Interested in Raven? Get in touch with us! There is an official IRC channel now (#ravenports on Freenode) which is probably the best place to talk to other Raven users or the porters and developers. You can of course also send an email.
If you want to contribute, there is now a new "Customsource" repository on GitHub that you can create pull requests against. Feel free to contribute anything from finished ports that might only need polish to WIP ports that are important for you but you got stuck with.
Customsource GitHub Repository
There are many other means of helping with the than project then doing porting work, though. Open issues if you find problems with packages or have an idea. Also tell us if you read the wiki and found something hard to understand. Or if you could use a tutorial for something - just ping me. Asking doesn't hurt and chances are that I can write something up.
Got something else that I didn't talk about here? Tell us anyway. We're pretty approachable and less elitist than you might think people who work on new package systems would be! 😉