💾 Archived View for gemini.circumlunar.space › users › kraileth › neunix › eerie › 2018 › flying_wit… 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 November 2018. The article has been slightly improved.
It has been a little over one year now that I'm with the Ravenports project. Time to reflect my involvement, my expectations and hopes.
Ravenports is a universal packaging framework for *nix operating systems. For the user it provides easy access to binary packages of common software for multiple platforms. It has been the long-lasting champion on Repology's top 10 repositories regarding package freshness (rarely dropping below 96 percent while all other projects keep below 90!).
Repology Packaging Hub Website
For the porter it offers a well-designed and elegant means of writing cross-platform buildsheets that allow building the same version of the software with (completely or mostly) the same compile-time configuration on different operating systems or distributions.
And for the developer it means a real-world project that's written in modern Ada (ravenadm) and C (pkg) - as well as some Perl for support scripts and make. Things feel very optimized and fast. Not being a programmer though, I cannot really say anything about the actual code and thus leave it to the interested reader's judgement.
If you're interested in a more comprehensive introduction to Ravenports, I've written one half a year ago as well as a little update and more information about Ravenports and DragonFly BSD.
Ravenports: A modern, cross-platform package solution
Ravenports: Status update and the Dragonfly case
Ravenports has initially been developed on DragonFly BSD. When I became aware of it, it had already been ported to work on Linux, too. I liked the idea of the project, but had no DF or Linux boxes available for tinkering and didn't feel like setting one up. Thus I moved on.
As I checked back a little later, FreeBSD support had been added. Since I had just lost my excuse not to try it out right away, I started playing with it - and was pretty happy. At that time I had trouble to get a port that I wrote into FreeBSD's Ports Collection and thought that Raven could be an excellent playground to learn something and get a bit of experience that might help me later with FreeBSD.
The Xfce4 desktop - installed via Raven (PNG)
I've long changed my mind, though! Raven is rather similar to FreeBSD's ports system in many ways but where it differs it's clearly superior. Also I love the cross-platform aspect and thus Raven is simply the better place for me to make home.
This year saw the introduction of Solaris / illumos support that I tried out on OmniOSce. Also Darwin support landed [but was later put on hold again], upping the count of supported platforms to 5 already! Not too bad for a young project, huh? While Raven does work on all five platforms now it does so to varying degrees. But more on that later.
The Ravenports project consists of multiple Git repositories hosted on GitHub. The first one is _Ravensource_ which most importantly holds the "raw" ports as they are written by the porters. It's the most busy repo with over _5.200_ commits since March 2017 (including almost 500 by me).
Then there's the actual _Ravenports_ repo that mostly contains the buildsheets which are compiled from Ravensource. It has over _1.400_ commits right now.
Finally there's the repo for the _Ravenadm_ command-line tool. It's approaching _900_ commits since February 2017.
There's still more to Raven like the _Pkg_ package manager from FreeBSD (that was modified to add Zstd compression support) or _libbsd4sol_, a portability library which allows building code on Solaris that uses BSDisms (which was needed to add support for that platform to Raven). Most of the work on all repos was done by Ravenports' inventor, John Marino alone.
Installing the xfce-single-core meta-package (PNG)
With over _100 pull requests_ and more than _20 issues_ it's clear now that there's some interest in the project. Raven is still very small, though, with 6 people having contributed ports so far. After learning the basics and opening pull requests for half a year, I've been granted write-access to the source repository. Just recently I was able to push my 100th active port (there have been ports that became obsolete and were removed).
In general I'd say that there could of course be more people around and that the project would benefit from being able to provide more packages - though more than 3.200 is not bad at all! Also it's good that there seems to be a growing user base which is even more important than having more porters join in. From my point of view, Raven is a healthy and fast-moving project. Still young, but doing well and heading in the right direction.
There have been some pretty big changes that happened with Raven over time. Initially John started with a GCC6-based toolchain, only to switch to GCC7 when that was released. That was before my time with the project, but I witnessed the switch to GCC8.
Changing the toolchain certainly is a major interruption and most people are advised to just wait for the official repository to be re-rolled and then update. I had some bad luck in this regard - literally the day after I finally completed a working (and almost complete) set of basic packages for the FreeBSD_i386 platform, I faced the change to GCC8. Due to a lack of time I still haven't repeated the switch on i386 (but I plan to do it sometime).
Other changes that always have a huge impact (causing lots and lots of packages to be rebuilt) is adopting a new version (as well as dropping an old one) of the popular interpreter languages like Python, Perl and Ruby. Ravenports always supports two versions of Perl and Ruby and two versions of Python 3 (as well as 2.7 for now). So when Python 3.7 was released, 3.5 was removed and Perl 5.24 had to go when 5.28 was added.
Recently the former LLVM port that included everything regarding LLVM was split (LLVM, Clang, lld, openmp). Also now and then new statements are added to Ravenadm, so that old versions cannot work with a new release of the buildsheet repository (which is called "conspiracy"). But this is pretty easy to work around compared to the changes mentioned before.
So on the whole, Raven has proven that it can easily stand even big changes. For me this is essential to build up faith in a project. And Raven is doing well in this regard.
There are lots of people who will want to use Raven on servers. That's totally fine of course. But for a project as ambitious as Ravenports, it's necessary to provide a somewhat comfortable environment for the developers and the users alike. If it doesn't manage to become a daily driver for people it cannot succeed.
For that reason I decided to work towards good desktop support for the little dev machine that I dedicated to my work on the project. When I started, X11 was already working and Openbox had freshly landed in the repos. So I had a simplistic environment to work with: Openbox + Xterm. However I could not even change my keyboard layout! Therefore I wrote a port for _setxkbmap_ and eventually it was accepted as the first outside contribution to the project.
Next I did some work to get the FLTK toolkit and the EDE desktop in. Then I added my favorite terminal emulator, Sakura. This worked out pretty well and the biggest shortcoming at the end of 2017 was that there was no real graphical browser available. A lot has changed since then!
Today you can choose between multiple window managers, both floating and tiling:
And in case you prefer a real desktop environment, there are also several available:
Two graphical web browsers are available, Surf (which is deliberately simplistic and does not even support tabs) as well as an old version of Firefox (the last one that builds without Rust). This is certainly not perfect but much better than a year before.
Also other important programs are available, including LibreOffice! Last month the Apache webserver landed - which is a pretty complex port compared to many others.
Are there packages you'll miss? Most certainly. However there's a _wishlist_ now with ports that people would like to see created (please feel free to add more requests there). And that's another good step ahead. Currently it's almost 120 items long. Fortunately there's been some success, too, and 26 requested ports have been created and taken of the list so far.
There are some future ports that will require lots of effort (hint: Help wanted!). The most important one that blocks some other important ports is the _Rust compiler_ [which landed not too long after I wrote this article! It's only missing on Solaris so far]. There has been some work done on this but it's not done, yet. Another real beast is TeX [successfully added in mid 2020]. This totally must be supported at some point. Current versions of Firefox and Chromium are often asked for. And somebody even requested Eclipse (which needs Java!). So there's definitely more than enough work to do.
Using Raven on Linux works, but there are some flaws. Initially the Pkg package manager used to crash quite often. John traced that back to a bug in the version of SQlite that's used internally by Pkg: The problem only struck on Linux and was fixed by using a newer version instead. While it's much better now, there's still the occasional problem with it.
While the packages from the repo work fine on Solaris 10u8 and above as well as illumos, the exact version 10u8 is currently required to build packages. This is due to Solaris not being able to work with older system libraries in the build chroot. It would be great to haven an alternative ravensys-root for any illumos distribution (OmniOSce, SmartOS, Tribblix, ...) available so that interested people without access to that specific closed-source Solaris version can develop Raven on that platform.
I don't know how well Raven works on Darwin. Since I don't have access to any macOS machines and PureDarwin is not really ready, yet, there's currently no chance for me to test it. I intend to buy an older MacBook or something in the future, though, if I come across a fair offer and have some money available to spend on my hobby.
Some ports are not available on one platform or the other: illumos mostly because they'd require patches to build and Linux often because it relies on additional libraries that have not yet been added to Raven. And then there's a lot of packages that are mostly untested. All of these issues can be fixed, of course. All of those require a larger user-base, though. So it's probably the best strategy to keep working on making Raven attractive to more users and address things when the right people show up.
Currently Raven uses the primordial X11 input drivers (xf86-input-keyboard and xf86-input-mouse) on all platforms. In 2013 Linux pioneered support for generic input drivers by exposing the kernels "event devices". Not too much later many Linux distributions adopted _xf86-input-evdev_. In 2014 there was a GSOC project to add evdev support for FreeBSD. Like many projects it came along a good part of the way but eventually was left unfinished. It was picked up and completed by a FreeBSD developer in 2016.
Xfce's settings and applications menu (PNG)
To use it, a special kernel had to be built so it would expose the _/dev/input_ device nodes. Then a sysctl had to be set - and eventually X11 had to be patched for emulated udev support... Why would anybody want to do all this just for different input drivers? Multi-touch support is just one valid reason. Another one is that having evdev-based input drivers is half the way to eventually support _libinput_, too. And that is one of the prerequisites for _Wayland_!
This month FreeBSD has finally enabled evdev support in the GENERIC kernel in both -CURRENT and 12-STABLE. That means the upcoming FreeBSD 12.0 will not support it out of the box, but most likely a future 12.1 will. DragonFly BSD has also grown support for event devices and people are interested in working towards Wayland. I hope that we'll be able to get xf86-input-evdev working with our X11 (on DragonFly, FreeBSD and Linux) next year.
I'm taking a little break from Xfce now (but plan to port most of the remaining components later to make it a well-supported DE in Raven). There are a few things I have planned like adding Linux support for OpenVPN (it depends on some libraries and programs that are Linux only which are not yet in Raven). Also I intend to take a look at adding some more Qt5 components and write a few requested ports. And finally I want to write another post next year - a tutorial on using Ravenports and creating new ports.
So keep flying with us - it's exciting times!
