1428 words by attila written on 2015-09-18, last edit: 2015-09-18, tags: open-source, openbsd, perl, portsPrevious post: OpenBSD Tor Browser Ports Status Update: July 2015, 4.5.3 (yes, I know, it's August)Next post: SQhelL

You wouldn't know it from reading this blog but I actually do write software on occasion. I've been changing the way I do things in general, ditching old bad habits for new ones (always the optimist, that never changes). To death with Stinking Linux Thinking: simplicity and spending more time on the shoulders of giants is a better way to get things done.

I do all my development now on OpenBSD-current, and one of the ways I want to be different is by contributing more. At the very least I can contribute a port of something when I need it and it isn't there, but getting involved in general (by action, not just words) is a constant goal of mine, albeit mediated by my own wierdness. Whenever opportunities present themselves I'm trying to take them up as challenges instead of skulking off to do something else. Since I've been meandering back towards Perl as my HLL/non-systems implementation language (C being the latter) I've been trying to modernize and see what The Cool Kids are up to.

Practically speaking, this means slogging through porting a bunch of Perl modules to OpenBSD that I want to use, if only indirectly. Most of them are deep dependencies that I'd honestly rather not have, but I want some the modules that do the depending, so there's nothing for it but to port them, although I'm beginning to think there might be a better way in some cases... I just don't want my first instinct to be screw it: this sucks when I run into tangled nests of dependencies I'm not all that happy about. Instead I'm trying to understand why and how this has happened and see what constructive results I can get out of it... this is totally boring and not nearly as much fun as getting drunk and cussing, I'll admit. It's like I'm turning into Bob Ross or something ("let's write a happy little class, with a happy, simple little API... just get it on the canvas there, next the the fluffy, happy clouds"; soundtrack: Heroin by the Velvet Underground).

It's been a few years since I was constantly hacking in Perl. I feel like I've been in a far away land where spaces were all-important but what was between the spaces was somehow less important. Now I'm back in The Land of Radiant Code Density where sigils and strictures reign supreme. The camel is a warm-blooded animal, after all, unlike the snake.

A few things really strike me, perhaps just belatedly because I hadn't been keeping up on so-called Modern Perl (wait, I thought Perl was permanently post-modern, no?).

Hey... I'm not that type of {guy,variable,object}

There seems to be an ever-growing pile of modules that attack the "problem" of typelessness in Perl on many levels, frequently taking exactly the same outer (sugar) approach while using radically different approaches internally... maybe. Or maybe it's just the worst case of NIH ever, I don't know. Function::Parameters vs. Kavorka (vs. other stuff, I think, I started to glaze over a bit). Type::Tiny vs. ... nothing, it chooses instead to subsume everything else rather than fight (I guess?). Do you want type signatures in your functions? Return types? Real classes? Fake classes that you can't tell are fake? All of the above? You can have it all, in the same address space, maybe even without knowing what you've done.

It seems like typeless languages always end up growing a serious case of type envy over time; likewise, strongly typed languages frequently grow mechanisms to shrug off the Tyranny of Types. I guess it's just another instance of curly vs. straight: the peoples always want whatever they don't got, thus: hair salons.

Moosient Madness

Moose's impact is absolutely enormous, and the set of modules that are answers to / arguments with / augmentors of Moose is just crazed. Moops is especially nuts in my opinion, but I admit I don't have a good feel for how much any given region of the extended Moose venn diagram is actually inhabited by real software that uses it and not pet projects that are more evangelical in nature. There are many ways in which the Moose venn diagram and the ad-hoc type system diagram interact as well; Moose's psychic footprint extends well beyond mere OO (although pure OO types will tell you there is no place beyond "mere" OO).

I'm working on drawing The Definitive Diagram of Moosient Confluences. I just need a bottle of single malt to do it; please donate, it'll be great, I swear.

Just Do It... even if it Makes No Sense (TMTOWTDI, remember?)

The Linux mindset ("just do{} it" perhaps?) has metastasized in parts of the CPAN namespace to the point where it's difficult to comprehend. I specifically am thinking of the Alien::* way of interfacing with external libraries. Modules like Alien::GCrypt for instance (which something I need depends on) are especially problematic. The idea here is Alien::Foo is some kind of dynamic, on-the-fly, don't-worry-about-the-details Perl interface wrapper to libfoo, whatever that is. If libfoo is installed on your system, it loads it with DynaLoader or something and does a magic elf dance. If it isn't installed (and this is the problem), the source code is DOWNLOADED on the fly (what?), compiled while you wait (wait... What!?) and the resulting .so/.dll/.dynlib/.nippon_goo files are stuffed lovingly into some hidden directory where Alien::Foo will find them with DynaLoader and It All Just Works so Don't Worry 'bout The Guvament (okay, seriously... WHAT!?).

My problem with all of this is that there is frequently already an interface to the library in question. In the case of libgcrypt, for instance, there is not one, but two Perl interfaces besides Alien::GCrypt, which really leaves me wondering: why? Both of the other interfaces are the traditional XS-based link-it-up-at-build-time kind of interfaces that Perl supports so well. And yet, the module I really want for my own use (Protocol::OTR) depends on several Alien::*-style interfaces.

Here's the rub in this (and at least one other) case: Alien::Base provides common code to check if a library is installed, and it uses pkg-config to do so. This is great as long as the library involved uses pkg-config. You'd think this is sort of a de-facto standard at this point, but it turns out there is or was hostility towards pkg-config in certain quarters... like the land of GnuPG, where libgcrypt hails from. Libgcrypt ditched pkg-config support sometime in 2005, yet Alien::GCrypt blindly tries to use pkg-config to find libgcrypt; as far as I can tell this will fail 100% of the time on all platforms (success!?), which means the code that downloads the source if necessary and compiles it on the fly comes into play... which is not going to fly under OpenBSD, for what I consider good reasons. Ports are not supposed to do things like download stuff on the fly when you build them. I think this is sane and sensible, for the same reason I think software that phones home for updates is poorly considered.

This is where my "let's just f'ing port it, then" attitude runs into a wall that I must climb by non-technical means, and I'm always bad at that. I've probably spent more time writing this dumb post than engaging the relevant community (the gnupg-devel mailing list) to see if they would mind (re)sprouting pkg-config bits. The thing is, I can kind of see their point in a way, or I could see it in 2005. I can also see how it might be considered annoying for someone to ask for a "feature" request like that (please re-add something you ditched for what you thought was a good reason a long time ago) because some new, clueless interface wants to do something that you don't support (using pkg-config to find libgcrypt).

No matter what, I have to do something to make progress. I just had never found myself in this position before...

Ah, well, just a note before I go back below.

Copyright © 1999-2023 by attila <attila@haqistan.net>. All Rights Reserved.