1 |
On Friday, 25 January 2019 11:18:17 AM AEDT Alan Grimes wrote: |
2 |
> Michael Jones wrote: |
3 |
> > My reason for replying initially was that I didn't think it was fair |
4 |
> > to make light of users who don't expect to *need* to scrutinize the |
5 |
> > output of emerge every single time they run it. Those people exist |
6 |
> > (hi, nice to meet you), and it's not fair to say they're wrong or |
7 |
> > somehow making a grave error in judgement. |
8 |
> > |
9 |
> > It's entirely fair to say that they are treading on thin ice, and that |
10 |
> > if they choose to do this they should understand the risks, but it's |
11 |
> > not fair to say they're automatically wrong to use the tool in a way |
12 |
> > that the tool allows itself to be used. |
13 |
> > |
14 |
> > Either way, we don't need to turn this into a long and in depth |
15 |
> > discussion, so I probably won't reply to the list again unless you |
16 |
> > have any specific questions or concerns for me. |
17 |
> |
18 |
> Thank you for the reasonable response. |
19 |
> |
20 |
> Dale, of course, has spewed hate at me for simply trying to make my life |
21 |
> as convenient as possible while still using Gentoo over here without |
22 |
> even providing a satisfactory answer as to why. |
23 |
> |
24 |
> |
25 |
> My experience with Emerge is that it goes out of it's way to be obscure |
26 |
> and conceales huge amounts of information from the user by default, like |
27 |
> all unix programs, and must be coaxed with a litany of flags, |
28 |
> parameters, and environment variables to produce any useful output at |
29 |
> all. Whenever it's output pattern changes I need to go do research to |
30 |
> re-enable whatever it decided to hide this month. |
31 |
|
32 |
Portage does not "go out of its way to be obscure", it just offers optional |
33 |
functionality in packages differently to binary distros, offering them as flags |
34 |
on the parent package rather than splitting them into discrete sub-packages. |
35 |
If a binary distro were to have a package that it splits component features |
36 |
into sub-packages, you'd be in the same situation. |
37 |
|
38 |
Point is: if you are the admin of the system, you should check the updates |
39 |
before committing to them, regardless of whether it's a binary or from-source |
40 |
distro. Updates that break the tree are usually caught and resolved quickly, |
41 |
particularly for key packages like openssl. |
42 |
|
43 |
But hey, it's your system. :) |
44 |
|
45 |
> At this point, I need to update about 25% of my system, or on the order |
46 |
> of 460 packages. Going through this list manually simply is not feasible |
47 |
> or even productive. Having tried several approaches to starting the |
48 |
> update including emerge --update system, emerge --update world, and |
49 |
> emerge --update packageX, I have decided that the only command that will |
50 |
> sucessfully update my system in it's present state is emerge --emptytree |
51 |
> world . The singular obstacle to that working appears to be the absence |
52 |
> of those patch files. |
53 |
|
54 |
That sounds like you're not updating correctly. `emerge -uUDa @world` is |
55 |
generally all you should need for keeping the system up to date. Very |
56 |
occasionally you'll need to do other things, but not as a rule of thumb. Note |
57 |
that this will exclude some packages where a flag was added *in a disabled |
58 |
state*, so it shouldn't affect the resulting built package. You can include |
59 |
those by changing the 'U' to an 'N'. |
60 |
|
61 |
You might also be interested in the --keep-going flag, rather than spamming |
62 |
countless --resumes. This allows portage to build what it can and leave |
63 |
anything that fails (and dependents that subsequently can't be built) to be |
64 |
resolved and re-tried at the end (providing you read the output showing what |
65 |
failed and what couldn't be built as a result). |
66 |
|
67 |
Also note that you can expect to encounter a few more bugs if you're using |
68 |
~arch. That's why it's known as "testing" and why it isn't enabled by default. |
69 |
|
70 |
> Now, back to the problem at hand. |
71 |
> |
72 |
> Since 2004, I have been using "emerge --sync" to update my portage tree. |
73 |
> I understand that it accesses a local list of mirrors and then runs |
74 |
> rsync against one of those. On spinning media hard disks it is helpful |
75 |
> to pre-cache the portage tree as shown in my scripts, on SSD systems, it |
76 |
> is simply harmless. I refreshed my mirror list and selected either HTTP |
77 |
> or RSYNC mirrors from across the USA. |
78 |
|
79 |
This sounds like either a broken mirror (which does happen from time to time) |
80 |
or options on your system that are preventing it from syncing all the required |
81 |
files. It would be useful to see your actual configuration (in the form of an |
82 |
`emerge --info`). |
83 |
|
84 |
> The problem is NOT with emerge in that the files that it complains about |
85 |
> not being present are in fact not present. I tried to find them on |
86 |
> google and only found changelogs, not the actual files in a downloadable |
87 |
> state that I can add manually. I am still angry with Emerge for not |
88 |
> updating all packages for which those files are not required or even |
89 |
> compiling packages until it encounters one for which it does not have |
90 |
> the files. |
91 |
|
92 |
See my above note about --keep-going. |
93 |
|
94 |
> I prefer to obey the server's admonition against updating more than once |
95 |
> a day, however this is an emergency and I have run sync against it maybe |
96 |
> a dozen times. I have no reason to expect that there is any discrepency |
97 |
> between the files I have and what's actually on the servers unless there |
98 |
> is an entirely different set of servers out there which actually do have |
99 |
> the files I need or a completely new and different way to sync them, |
100 |
> (WTF IS Eix? ) . =| |
101 |
|
102 |
Eix is primarily a search/indexing tool, that also wraps functions such as |
103 |
syncing. You don't need it, but it can be useful. See it's wiki page[1] for |
104 |
details. |
105 |
|
106 |
Yes tools have optional flags that change how they behave; but it's not in an |
107 |
attempt to confuse you as you seem to think. You just need to spend the time |
108 |
to learn the tools you're using, the same as any other tool you get anywhere, |
109 |
online or offline. Why not have a look at the man pages or wiki's for the tools |
110 |
you use before claiming everyone's out to get you? ;) |
111 |
|
112 |
[1] https://wiki.gentoo.org/wiki/Eix |
113 |
|
114 |
-- |
115 |
Sam Jorna (wraeth) |
116 |
GnuPG ID: 0xD6180C26 |