⋔ home ⋔ about ⋔ links ⋔ license ⋔ archives ⋔ rss ⋔
1428 words by attila written on 2015-09-18, last edit: 2015-09-18, tags: open-source, openbsd, perl, ports ⋔ Previous 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?).
{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.
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.
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-2024 by attila <attila@haqistan.net>. All Rights Reserved.