Joe,
You have stumbled upon my biggest "beef" and complaint about "open source" packages -- when it came time to come up with a "package manager" -- whether you use yum or RPM or debian's deb packages etc., etc., they all just basically re-invented the old Windows "DLL Hell" problem, on steroids!
So you can quickly end up installing one OSS package, then at some other time, you try to install a different OSS package, and now either it refuses to install, saying there is a conflict, or even worse, the first one quits working because you inadvertently updated something that it "depends on."
My recommendation for how to avoid this is to use a separate sub-directory for each "set" of related OSS tools, and install all the needed stuff into there ... then you can just zip it all up, (or in Unix terms, create one big "tarball"), and if you need to install it on another system, just unzip or untar it all again. In other words, each product or tool has its own "top-level" directory that contains ALL of the "dependencies" needed for that tool. So, it is "self-contained." (Sure, it uses more disk space, but it solves a lot of problems and saves a lot of frustration, long term.)
This approach is more or less how Windoze ended up fixing "DLL Hell", by allowing different versions of the same named .DLL to be installed into each product's own subdirectory. (a local copy).
ADVANTAGE: once you get something "working" if you keep it segregated in its own separate IFS sub-tree, there is less chance that some other OSS package will suddenly cause it to "break" or fail.
NOTE: you may be able to continue to use YUM etc. to initially install stuff, and then immediately move all of the various components and dependents to a new separate "home" directory for that tool or utility or language, etc.
That way, the next time you use "yum" to install something else, it should not find that stuff, or at least not overlay it.
You can also use good old save files and the SAV and RST command to save and restore things that are installed and organized this way. :-)
Just saying ...
You also might be able to use "chroot" to accomplish more or less the same idea ... but as I understand it, once you leave the "chroot" environment, that stuff all "goes away" so you would need to re-install it all again the next time.
Hope this might help, conceptually ...
All the best,
Mark S. Waterbury
On Friday, December 18, 2020, 2:24:13 PM EST, Joe Pluta <joepluta@xxxxxxxxxxxxxxxxx> wrote:
I appreciate the thoughts, John, and concur. To learn about open
source, and installers, and some of the intricacies of this particular
endeavor I think starting on my PC (I think I mentioned WSL Ubuntu,
which is a pretty slick package) would provide a much more fundamental
understanding. But the original draw for MKDocs was the "do these three
command and you're up" concept, and I tried to stay true to that.
That being said, it might be time to throw in the towel. Even my
Google-foo was unable to give me a brief lay person's overview of the
ResourceConflict issue I am having, and so it might be time to redirect
my efforts a little bit.
On 12/18/2020 1:13 PM, John Yeung wrote:
I was drinking from the firehose at that particular
moment. [...] There really is a bit of a bootstrap,
both technically and philosophically, to embrace Open Source.
The hurdles are bigger if you are introducing yourself to it on PASE,
because PASE is a little weird.
Not insurmountable by any means, but it does make for that fire-hose experience.
If you have the time and interest, I like the approach of learning
some piece of open source technology on a mainstream platform (like
your own personal computer), and then taking that knowledge over with
you to PASE. That way it's clearer what is a quirk of (say) Python,
versus a quirk of Python-on-PASE.
Not only that, but then it's also easier to work with all your
favorite local tools like editors and so forth.
John Y.
midrange.com
