1 |
On 2013-02-14, James wrote: |
2 |
|
3 |
> So, my latest ideas is to "sync up" and then wait one week |
4 |
> before acutally installing those new packages. This would |
5 |
> allow the fodder that the good folks on this list catch, |
6 |
> bitch about (um, I mean file bug reports) and fix, to |
7 |
> occur first; then I can complete the package update |
8 |
> cautiously avoiding an "emerge sync". |
9 |
|
10 |
The fun thing is that this is supposed to be why we do have unstable |
11 |
keywords. Some of the breakage which happened and hit the stable tree |
12 |
with no timely news item was actually discussed for some time before in |
13 |
the -devel list. You may want to follow that list too. |
14 |
|
15 |
That "sync up" you talk about is effectively equivalent to having ~amd64 |
16 |
for amd64. |
17 |
|
18 |
> But when you "emerge sync" if to do the updates immediately, they'll be |
19 |
> the latest packages. If I do a "emerge sync" and wait |
20 |
> 7 days to begin updating the packages, I'll be delayed |
21 |
> by one week, and have a one week of buffered fixes for added |
22 |
> problem filtering. But those fixes might not be available |
23 |
> without a fresh "emerge sync"? |
24 |
> |
25 |
> |
26 |
> When time permits I CAN CHOOSE to "emerge sync" and then immediately |
27 |
> update the packages and parse through the issues mostly. Call |
28 |
> this the stable-stable approach to gentoo updates. |
29 |
> |
30 |
> Does anyone see any problems or a better way to stay one-week-delayed ? |
31 |
|
32 |
Packages with problems simply shouldn't hit stable. I'd rather just do |
33 |
--sync and perform world upgrades, and I would just keep an eye on the |
34 |
triggered updates, in order to spot any potentially problematic package |
35 |
(like c++-based libraries). |
36 |
|
37 |
> I'm increasingly managing more Gentoo systems, particularly embedded |
38 |
> and server based gentoo systems and that is the source that compounds these |
39 |
> time-sink-issues for me. Maybe some external-integrated management approach |
40 |
> such as CFengine is my answer? |
41 |
> |
42 |
> Your comments and thoughts are most welcome. |
43 |
|
44 |
Your problem does not seem to be emerge --sync, but that you run |
45 |
commands that cause existing upgrades to be applied on a system-wide |
46 |
basis. |
47 |
|
48 |
If there is a fix you need/want, re-emerge that specific package, and |
49 |
let the others wait. Only the strictly needed dependencies should be |
50 |
pulled this way. You're not forced to use "-DuN world" or even "-DuN" |
51 |
every time you want to upgrade something. |
52 |
|
53 |
-- |
54 |
Nuno Silva (aka njsg) |
55 |
http://njsg.sdf-eu.org/ |