The article I linked yesterday about Ravenports got me wondering about what package are most popular. avalon.dragonflybsd.org is the default binary package archive for pkg, and it has httpd logs back to 2013, so I collated some information.
I read out a list of packages, and weighed them according to how recently they were downloaded. I also mushed together all the py/ruby/p5/php numbered packages, and excluded lib*.
After all that… there’s a lot of noise. One install of any desktop environment pulls in hundreds of packages automatically, so it’s hard to tell what’s installed by a human and what’s installed by dependency. That being said, here’s some highlights. This is me applying an arbitrary value and then arbitrarily snipping out a list… but it’s fun to see if nothing else.
eerielinux has written an exploratory article about Ravenports. It’s worth a read; Ravenports has been growing actively. You can install it in parallel with dports on DragonFly, or on a number of other operating systems.
Mixed in with the other documentation on the DragonFly website is a “how to build a release” explanation. I use it every time there’s a new DragonFly version. If you were wanting to build a DragonFly ISO/IMG with changes or different preinstalled dports, I’ve added some notes about what’s relevant for non-release building.
We used to have “GUI” releases of DragonFly which were based on the nrelease process installing pkgsrc packages and adding some configuration files. It doesn’t happen now mostly because nobody has had the time to reconfigure for dports; if you were looking for a project this weekend, may I suggest…?
DragonFly has had NX (Non-eXecutable) support for some time. It’s now on by default for read operations in DragonFly master – not the current release. You can step it up to level 2, for write operations, with a loader tunable, but it may cause issues with dports.
If you’ve ever wondered what packages are needed to build a DragonFly release: here they are in one dports metapackage.
Reduce, the “second oldest computer algebra system”, has been ported to DragonFly (and there’s work on other BSDs). The post about this has lots of links to more information; if you’re a Maple or Mathematica user, this will definitely interest you.
There’s a plugin for pkg, called pkg-provides, which will tell you what package(s) contain the filename you provide – installed or not. I didn’t even know pkg had a plugin system. Anyway, it works on DragonFly, as the author notes.
Totally last-minute summary, but I’m hitting every BSD category.
The default options on the math/py-numpy port slowed it down. Francois Tigeot noticed, and committed a change that takes advantage of all processors. Read his note to users@ for details.
I say “one more” like I know when this saga will end. If you are using the devcpu-data port to update your processors, you’ll need to add
to your /etc/rc.conf, as Sepherosa Ziehau points out.
A full slate of BSDs this week.
Because of the major version number change, there’s no packages built for DragonFly 4.9. Your options are to either update to 5.1 (which you probably meant to do anyway if you are running current) or manually point to the newest packages. Or just build from dports.
For clarity, this does not affect you at all if you are running 5.0 release. It only affects you if you are running DragonFly-current and have not updated in a while.
John Marino has assembled a new packaging and building system. It’s called Ravenports, and he wrote a short intro, and has a filled-out site to go look at.
This is big news, in part because he knows what he’s doing (John worked on dports and created synth) and because it’s cross-platform. The prior work on synth is part of the reason DragonFly works so well under pressure – the “build everything as fast as possible as complete as possible” strategy makes a great stress test.
There’s no need to change software management strategies yet. It can be used at the same time as dports, so it doesn’t necessarily change anything for the next DragonFly release.
Lots of links this week – so many I’ve already started next week’s post.
If you’ve had odd behavior with node.js (which I have) on DragonFly, it may be fixed now.
I’ve waited to post this because it’s a bit complicated, but here is the summary: dports didn’t get updated with new binary builds for a while because Rust stopped working, which killed Firefox. Michael Neumann got Rust working again, and packages are updated.
(Use -f if you have upgrade troubles.)
If you happen to get missing shared library errors when running something installed via dports, you may have installed during a short period where this previously mentioned bug had bit. The fix is to replace with known good binaries, completely.
Matthew Dillon noted some OpenVPN problems, requiring him to disable compression. I don’t think this is a DragonFly problem, or even necessarily a BSD problem, but it’s worth mentioning in case you run it.
There’s a bug with shared libraries in pkg(), which may bite you when upgrading. It’s present in version 1.10.1 at least, so you may want to wait for this fix to be applied before your next upgrade.
A tip that might be useful for some readers: Mohammad BadieZadegan posted that he had a poor network connection, and so was having a hard time installing packages. If that bites you too, there are some pkg.conf options – starting with FETCH_TIMEOUT and FETCH_RETRY – that may help.