Dear Monks,
I was just asked for the second time in a year to resuscitate an event calendar and associated content management system I had installed for a client some years ago. It seems to have broken due to a FreeBSD upgrade both times. I'd like to know if anyone has an idea for solving this problem in the general case so I don't have to do this once a year. So far I'm thinking of:
- Just suck it up.
- demand the isp host the modules forever just for us. (they can't easily change isp)
- bundled precompiled binary using something like PAR pp.
- figuring out how to get these things to statically compile. (this failed, see below)
- hosting this or a new application for free for them on my (as yet nonexistent) new server just so this (important but poor) client has no hassles.
Last time the problem was solved by recompiling the modules. This time, it worked for half the system but I also had to install newer versions and still the rebuild seems not to have taken completely yet. As the emergency came right after the date of the release as given by uname, understandably this looks like a neverending battle. So what I have is, four or five perl modules compiled locally but that break when the shared libraries on which they depend are changed with the OS. It was bittersweet to find on the server the technical memo I had written to future administrators about the last time..
Obviously an upgrade would have been manageable if the system was properly administered, had its own machine, had a provider who told the client in advance about these things, had a provider who managed the required packages for us, if there was a real database, if the client would change providers, etc.
Well solving the problem requires debugging and rebuilding DBI,DBD::CSV,Text::CSV_XS, and SQL::Statement (which I did..) although I am still having trouble with dbi execute failing inexplicably so I am not done yet.
My questions after all this:
- I did try to make a static module (LINKTYPE=static) but it failed looking for a libperl.a and there was none in this version (5.8.0) of perl, though I think I did find an old version elsewhere on disk from an older (5.0050x) perl. Which might work? Anyway in this case it was a problem of not being able to rebuild Text-CSV_XS but the newest version built okay. Question is, if I somehow can build all modules static then am I safe in the future?
- There are two scripts. Would PAR's pp bundler/compiler solve the problem with elegance? (i.e. it would hopefully create two statically compiled executables which I would drop into the cgi directories, and be proof against future upgrades) Will PAR do all this and build statically automatically? (Yes I will rtfm)
- If I know the target is running (for now) FreeBSD 4.8-Release #3 on i386, could I build the executables (with PAR pp, or maybe by making static modules) in i386 (actually i686) linux and just upload to the BSD machine?
- I haven't seen anybody mention this sort of problem and to me this ISP is contributing to it, but lots of people must have similar problems I imagine. Has anyone used PAR or another bundler to develop a system proof against upgrades?
Thanks for your ideas.
Matt R.