* Weaver <wea...@riseup.net> [22-07/04=Mo 00:43 -0700]: >>> ... your day going?
* Will Mengarini <sel...@eskimo.com> [22-07/04=Mo 07:50 -0700]: >> Hairier than Gene Heskett's nostrils, because "up"grading Perl >> from 5.8.8 to 5.34.1 [caused a kind of failure normally fixed >> using the Perl module CPAN, but this time the failure caused >> CPAN itself to fail early enough that it can't fix *itself*.] * Dan Ritter <d...@randomstring.org> [22-07/04=Mo 11:34 -0400]: > Bullseye comes with 5.32.x; is there a reason that won't work for you? This is a 32-bit frankenlinux that's so old that even the 5.8.8 I was upgrading *from* wasn't available in any compatible package repository; I had to build *that* from source 9 years ago. At least back then I was able to apt-get source perl-suid; this time, I used the vanilla 5.34.1 tarball, and only after I'd built it did I realize how heavily the Debian source for 5.8.8 had been patched with new directories on @INC. At first I thought I could fix that by hacking /etc/profile and /etc/X11/Xsession, but as I kept studying the startup process I realized that even /usr/bin/screen is in /etc/shells, along with /bin/sash and /bin/es (which is actually interesting), so I had to say to hell with it, wait out the heat wave, and build the whole thing *again* just to get a Debian-compatible @INC. Only *then* did I find out about broken CPAN. Bullseye's package repository is as far out of reach as Tau Ceti. * Dan Ritter <d...@randomstring.org> [22-07/04=Mo 11:34 -0400]: > CPAN is a repository for Perl modules [...] but in general > using the Debian dh-make-perl package to pull a CPAN > module and convert it into a .deb will make you happiest. That fails because of the same Catch-22: dh-make-perl *depends* on CPAN, and CPAN *itself* is broken. All dh-make-perl does is wrap CPAN to integrate it with the Debian package system. But CPAN itself can't update any modules including itself. Any CPAN wrapper, such as dh-make-perl, will be unable to run, because CPAN itself can't run: it die()s (a fatal internal failure) during its initial configuration, because it depends on installed compiled modules that are no longer compatible with 5.34.1, but that can't be recompiled because recompiling them is CPAN's job. At <https://metacpan.org/dist/DhMakePerl/view/dh-make-perl> is the enormous list of compiled modules on which dh-make-perl depends (including CPAN), cheerfully ending with "and possibly others". The whole thing is based on Perl modules, and the only Perl that actually *works* now is the core executable! Soooo, I could theoretically reimplement CPAN purely in core Perl; but that's risky, because there's always a possibility that what I think is core Perl on which I can rely is actually also broken. It makes more sense to use another language completely. Ruby? Tcl? Sure ... but the best choice is actually the one we *know* will *always* be available to anybody in the same predicament on a frankendebian: Bash. * Will Mengarini <sel...@eskimo.com> [22-07/04=Mo 07:50 -0700]: >> Somebody needs to reimplement CPAN in Bash just so we can bootstrap a >> totally broken Perl without needing to run out and buy a new computer. At first it sounds crazy, because, well ... Bash?! But think broadly about what BedPAN needs to do for each broken module: (1) wget the source code from some mirror; (2) compile it by running the same command that CPAN would've run (to find which I can RTFS); (3) test it (again, RTFS); and, if it passed, (4) install it. * Will Mengarini <sel...@eskimo.com> [22-07/04=Mo 07:50 -0700]: >> I mean, how hard can it be (assuming you grok what CPAN >> actually *does*, which I don't yet, and know Bash, which >> I know just enough of to make Greg Wooledge hate me)? Steps 1 & 2 are each extremely complex processes, but each is completely encapsulated in a standard POSIX utility that does not depend on Perl and that is available on practically every non-embedded GNU/Linux system. Invoking utilities like that is what shell code is *for*. Step 3 invokes the output of step 2. Step 4 uses commands like mv, parameterized with shell variables set inside the BedPAN script where the user can easily edit them. Assuming I have to code BedPAN myself, I'll probably just use sudo and not bother to support su, unless somebody complains. Those 4 steps would themselves be wrapped in a monadic function defined in BedPAN; its argument would be the name of the module to install. A different monadic function would have run first, checking whether the module *needed* to be upgraded. (I'm not sure the best way to do that is by checking a mirror for the latest version; maybe it'd be better to run a local test, and accept the module in its older version if it passes its own test. I don't know yet.) Those 2 monadic functions would have been invoked from an outer loop that iterated through an array of modules that might need recompilation. The list needs to include every module that CPAN depends on to run. None of that Bash code seems particularly woolly to me. The hard part will be clawing through the CPAN sources to figure out what the Bash code needs to actually do, and that's only hard because CPAN is so general, supporting multiple operating systems, etc. BedPAN just needs to run on GNU/Linux, doing just enough to get CPAN able to take over. * Will Mengarini <sel...@eskimo.com> [22-07/04=Mo 07:50 -0700]: >> For extra fun, I have to interrupt soon because I *JUST* found out >> that my physician is retiring EIGHT DAYS from today, I'm ADHD and >> have already run out of methylphenidate, and that physician has been >> my only source; the only one I know in the Seattle area who isn't >> intimidated by a medically-competent client or offended that I consider >> my own body to be my property and not that of the physicians' guild. * Dan Ritter <d...@randomstring.org> [22-07/04=Mo 11:34 -0400]: > You may wish to ask your physician to recommend > you specifically to a younger doc, and vice-versa. You're right, and I will ask him to recommend to me a physician (or nurse practitioner - hmm) to whom he's also willing to recommend me (i.e your "vice-versa"). Sadly, (1) I've learned that the younger they are, the more likely they are to be full of I'm-a-*DOCTOR*-now gas, and (2) my current physician is such an affable guy that everybody likes him, so he might not be able to tell whether a colleague who's nice to *him* would also be nice to *me*. Still, I have to try; time's up. And I might not even be able to get a final appointment with him. I only found out Saturday afternoon that he's retiring next Tuesday! (I'm a cripple who lives in a walk-up, so checking snailmail is painful, and I do it as infrequently as possible.) It's pretty hard to get an appointment with only seven days' notice. (It'll be seven days tomorrow when the office opens for appointments; today is a U.S holiday.) So I'm doing this Perl hack without methylphenidate, and the Perl hack is urgent, because this frankendebian needs a new OpenSSH and OpenSSL, which depend on a Perl newer than 5.8.8. I know it's hard to understand how I got into this situation, which makes it hard to help; but I'm interested in anybody's advice. MCCOY: How can I grant you what I don't understand? SPOCK: Then employ one of your own superstitions. Wish me luck. [Silence and stares, then McCoy opens the hangar deck door. Spock walks across and into the Galileo. The doors shut.] MCCOY: Good luck, Spock. -- from ST:TOS 2x18 "The Immunity Syndrome"
