From: "Lewis G Rosenthal" Received: from [50.73.8.217] (account lgrosenthal@2rosenthals.com HELO [192.168.200.18]) by 2rosenthals.com (CommuniGate Pro SMTP 5.4.10) with ESMTPSA id 1774281 for ecs-isp@2rosenthals.com; Thu, 01 Apr 2021 16:06:42 -0400 Subject: Re: [eCS-ISP] links in the ticket To: eCS ISP Mailing List References: Organization: Rosenthal & Rosenthal, LLC Message-ID: <606635DE.109@2rosenthals.com> Date: Thu, 1 Apr 2021 16:06:38 -0500 User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:38.0) Gecko/20100101 Firefox/38.0 SeaMonkey/2.35 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi... On 04/01/21 01:41 pm, Steven Levine wrote: > In , on 04/01/21 > at 10:32 AM, "Lewis G Rosenthal" 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. I guess I should add something to the troubleshooting page, as I have actually run the disk out of space while performing a big update (test system, not production, obviously). >> 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. Well, right now, it doesn't discuss reinstalling the bootstrap at all, so yes, it does address the possibility of path issues and \usr\local (Package Manager Troubleshooting | YUM errors). Perhaps this could be clearer, though. >> 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. 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. >> 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. Yes. >> 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. Right. >> 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. 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. :-) >> 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. > 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 fail. An export file would be preferable, of course, but not guaranteed. I should add something to the best practices wiki about generating regular export files for recovery purposes (and not just for duplication). -- Lewis ------------------------------------------------------------- Lewis G Rosenthal, CNA, CLP, CLE, CWTS, EA Rosenthal & Rosenthal, LLC www.2rosenthals.com visit my IT blog www.2rosenthals.net/wordpress -------------------------------------------------------------