| 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/ |
Archives