On Friday, 25 January 2019 11:18:17 AM AEDT Alan Grimes wrote: > 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.
Portage does not "go out of its way to be obscure", it just offers optional functionality in packages differently to binary distros, offering them as flags on the parent package rather than splitting them into discrete sub-packages. If a binary distro were to have a package that it splits component features into sub-packages, you'd be in the same situation. Point is: if you are the admin of the system, you should check the updates before committing to them, regardless of whether it's a binary or from-source distro. Updates that break the tree are usually caught and resolved quickly, particularly for key packages like openssl. But hey, it's your system. :) > 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. That sounds like you're not updating correctly. `emerge -uUDa @world` is generally all you should need for keeping the system up to date. Very occasionally you'll need to do other things, but not as a rule of thumb. Note that this will exclude some packages where a flag was added *in a disabled state*, so it shouldn't affect the resulting built package. You can include those by changing the 'U' to an 'N'. You might also be interested in the --keep-going flag, rather than spamming countless --resumes. This allows portage to build what it can and leave anything that fails (and dependents that subsequently can't be built) to be resolved and re-tried at the end (providing you read the output showing what failed and what couldn't be built as a result). Also note that you can expect to encounter a few more bugs if you're using ~arch. That's why it's known as "testing" and why it isn't enabled by default. > 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. This sounds like either a broken mirror (which does happen from time to time) or options on your system that are preventing it from syncing all the required files. It would be useful to see your actual configuration (in the form of an `emerge --info`). > 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. See my above note about --keep-going. > 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? ) . =| Eix is primarily a search/indexing tool, that also wraps functions such as syncing. You don't need it, but it can be useful. See it's wiki page[1] for details. Yes tools have optional flags that change how they behave; but it's not in an attempt to confuse you as you seem to think. You just need to spend the time to learn the tools you're using, the same as any other tool you get anywhere, online or offline. Why not have a look at the man pages or wiki's for the tools you use before claiming everyone's out to get you? ;) [1] https://wiki.gentoo.org/wiki/Eix -- Sam Jorna (wraeth) GnuPG ID: 0xD6180C26
signature.asc
Description: This is a digitally signed message part.
