Ron Johnson posted on Fri, 17 Jun 2011 21:59:41 -0500 as excerpted: > On 06/17/2011 09:06 AM, Duncan wrote: > [snip] >> FWIW, it shouldn't require them for that. It'd either be a hard >> dependency, pulled in when pan is installed, or not required, as pan's >> decoding is built-in. (I haven't looked in awhile, but IIRC it >> includes its own slightly modified copy of IDR which decode library in >> the sources, statically linked. That's a bit of a no-no as apps are >> supposed to use the system lib for ease of maintenance and security >> update purposes, but the pan-bundled copy is modified for pan's own >> use, so it had to be included. > > Can you explain that? "Shouldn't" pan be modified be modified to use > the relevant shared libs?
I'd say yes, but I'm not a pan dev, neither do I actually code, so... Meanwhile, the directory is still there so I assume so is the lib, and it's uulib. My guess is that way back in history (before I got involved with pan enough to be building it from source and understand this sort of stuff), possibly a decade ago or more, uulib may not have included yEnc, and because yEnc was not an official standards-track specification for quite some time, it's likely that upstream uulib said no to patches adding yEnc support. Charles, or possibly the pan dev before him, would have been interested in yEnc for pan and so added yEnc support to the lib on his own, but then had to bundle it as upstream wouldn't take the patch. Then over time the bundled version likely diverged from the upstream version and it became difficult to switch back to uulib or some other external alternative, by the time they included yenc. At the time of the pan rewrite, presumably Charles was already familiar with his version and its bugs or lack thereof, so didn't switch back then, either. That's as I suppose it to have happened anyway. To be sure, I've no idea how close that might be, or not, to reality as it actually occurred. That has always bothered me since I figured it out, but I've never really seen any distro pan maintainers (or anyone else, really) complaining about it. Maybe I've got it all wrong somewhere. Or maybe it really is so modified from whatever original, that it's no longer worth trying to separate out. I don't know, but it still bothers me. But pan is generally well behaved in terms of OTHER libraries, yet another reason I've always found it odd that this one was included... -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
