In <list-1773710@2rosenthals.com>, on 04/01/21
    at 10:32 AM, "Lewis G Rosenthal" <ecs-isp@2rosenthals.com> said:

Hi,

We are looking at this from a couple of different perspectives. You are
approaching this from the standpoint of getting a working YUM/RPM
environment to make ANPM work.

Yes. :-)

I am looking at it from the standpoint of
getting a clean, fully-functional *nix subsystem.

Which is exactly what you need to generate a new bootstrap. :-)

My needs for doing a clean bootstrap install are unique, in that I need
to  start with that in order to update it for a new bootstrap release.

Exactly.

Thus,  0-cruft-tolerance is the order of the day. This is not the case
for users  who just need things to work, however, and if disk space is
down so low that  a few extra MB (in extreme cases) of leftover files
would make a difference,

As I've said before, if this is actually an issue in real life, it needs
to mentioned in the wiki.

This will require some testing. Again, this does nothing constructive if
the  cause of the conflicts lies in \usr\local or PATH/LIBPATH settings
in  CONFIG.SYS.

Sure, but doesn't the wiki cover these possibilities before even starting
to dicuss reinstalling the bootstrap.

startup  (unless the option is deselected), but \usr\local content will
always take  precedence, so this tree needs to be clean.

FWIW, I've never agreed with the design choices that give the content of
\usr\local priority in PATH and LIBPATH.  I've yet to be convinced it make
sense for the average user and, as we have found, can lead to unexpected
bustage of an otherwise working setup.

I understand your wish to have place to drop files for testing, but this
is not what the average user needs.

There is probably some plugin to customize breadcrumbs, which comes along
with all of the overhead of every other WordPress plugin - for a trivial
pursuit.

Such is the yin-yang of WordPress plugins.

I'd probably move the download operation to the top of the list, just
after  the user confirmation.

Absolutely.  I don't know how it ended up where it ended up in the list.
The list probably needs a few more sanity checks such as disk space just
in case the user forgets.  The goal is the help the user avoid a bootstrap
reinstall when it is not appropriate.

considered. (I would rename \usr\local in the procedure when we rename
the  existing yum.log, etc.)

My approach would probably be a bit different, I would probably require
the user to empty \usr\local before allowing the bootstrap reinstall.
They should have already done this when troubleshooting the broken Package
Manager, but not everyone reads at the same level.  The same is true for
CONFIG.SYS PATH and LIBPATH settings.  These are relatively easy to
validate.

It might be hard to determine the level of detail in yum.log and how to
parse it properly for package names as a result.

It would be better to work from an exported.yum, but I would assume that
someone that got themselves in state that required a bootstrap reinstall
is unlikely to have an recent exported.yum.  I'm also assuming they don't
have usable backup that would allow them to restore \usr \etc \var etc. to
a known working state relatively painlessly.