In <firstname.lastname@example.org>, on 04/01/21
at 04:06 PM, "Lewis G Rosenthal" <email@example.com> said:
>Hmmm... I'd need to think on this for a while before considering a change
>in my position. I've always thought that local should come first, and
>not just because that's how I test.
I've read arguments for both orderings. On linux the argument in general
is that having /usr/local/* first allows you to easily use a locally
built, usually newer, version of a system installed binary. This make
sense if you are building locally which the vast majority of OS/2 users
don't do. If experimental packages were built to install to /usr/local, I
might find the current /usr/local ordering more useful.
It's probably not worth changing the current ordering given the cost of
re-educating the user base. Those of us that want something different,
have the ability to make this happen.
>Either way, we want to ensure that nothing will take precedence over the
>bootstrap content in order to get a working YUM/RPM setup. Otherwise,
>we're just rearranging the spice drawer wil the pot continues to boil.
If the /usr/local content was the non-obvious cause of the need to
reinstall the bootstrap, this will become less non-obvious as /usr/local
is repopulated. That said I can't see how this could even happen given
the obvious troubleshoot step. In my way of doing things /usr/local would
have been elimated and a possible problem in an early troubleshooting
>Exactly my thoughts. If we're to the point of having to reinstall the
>bootstrap, assume that yum is completely nonfunctional, and perhaps
>(likely) Python, as well, so any of our Python scripts are likely to
It's hard to envision too many a scenarios where python and yum are
running that the system would need to have the bootstrap reinstalled.
>I should add something to the best practices wiki about generating
>regular export files for recovery purposes (and not just for
A wishlist item might be for ANPM to timestamp the exported.yum files. I
already do this manually.