Michael Jones wrote: > > My reason for replying initially was that I didn't think it was fair > to make light of users who don't expect to *need* to scrutinize the > output of emerge every single time they run it. Those people exist > (hi, nice to meet you), and it's not fair to say they're wrong or > somehow making a grave error in judgement. > > It's entirely fair to say that they are treading on thin ice, and that > if they choose to do this they should understand the risks, but it's > not fair to say they're automatically wrong to use the tool in a way > that the tool allows itself to be used. > > Either way, we don't need to turn this into a long and in depth > discussion, so I probably won't reply to the list again unless you > have any specific questions or concerns for me.
Thank you for the reasonable response. Dale, of course, has spewed hate at me for simply trying to make my life as convenient as possible while still using Gentoo over here without even providing a satisfactory answer as to why. My experience with Emerge is that it goes out of it's way to be obscure and conceales huge amounts of information from the user by default, like all unix programs, and must be coaxed with a litany of flags, parameters, and environment variables to produce any useful output at all. Whenever it's output pattern changes I need to go do research to re-enable whatever it decided to hide this month. At this point, I need to update about 25% of my system, or on the order of 460 packages. Going through this list manually simply is not feasible or even productive. Having tried several approaches to starting the update including emerge --update system, emerge --update world, and emerge --update packageX, I have decided that the only command that will sucessfully update my system in it's present state is emerge --emptytree world . The singular obstacle to that working appears to be the absence of those patch files. Now, back to the problem at hand. Since 2004, I have been using "emerge --sync" to update my portage tree. I understand that it accesses a local list of mirrors and then runs rsync against one of those. On spinning media hard disks it is helpful to pre-cache the portage tree as shown in my scripts, on SSD systems, it is simply harmless. I refreshed my mirror list and selected either HTTP or RSYNC mirrors from across the USA. The problem is NOT with emerge in that the files that it complains about not being present are in fact not present. I tried to find them on google and only found changelogs, not the actual files in a downloadable state that I can add manually. I am still angry with Emerge for not updating all packages for which those files are not required or even compiling packages until it encounters one for which it does not have the files. I prefer to obey the server's admonition against updating more than once a day, however this is an emergency and I have run sync against it maybe a dozen times. I have no reason to expect that there is any discrepency between the files I have and what's actually on the servers unless there is an entirely different set of servers out there which actually do have the files I need or a completely new and different way to sync them, (WTF IS Eix? ) . =| -- Please report bounces from this address to a...@numentics.com Powers are not rights.
