| 1 |
On 02/14/2013 11:26 AM, James wrote: |
| 2 |
> Hello, |
| 3 |
> |
| 4 |
> Context: Stable Systems with a few newer packages |
| 5 |
> (unmasked) in portage. |
| 6 |
> |
| 7 |
--snip-- |
| 8 |
> |
| 9 |
> So, my latest ideas is to "sync up" and then wait one week |
| 10 |
> before acutally installing those new packages. This would |
| 11 |
> allow the fodder that the good folks on this list catch, |
| 12 |
> bitch about (um, I mean file bug reports) and fix, to |
| 13 |
> occur first; then I can complete the package update |
| 14 |
> cautiously avoiding an "emerge sync". |
| 15 |
|
| 16 |
I suppose you could set up a weekly cron job (say on a Saturday) to do |
| 17 |
something like: |
| 18 |
|
| 19 |
emerge -fuDN world > proposed_change.txt |
| 20 |
|
| 21 |
Then a few days later (say Wednesday?) email that file to yourself so |
| 22 |
you know what changes are being proposed. This will give you a |
| 23 |
"snapshot" in email of changes week-to-week. I've done this before and |
| 24 |
you'll just get output like this (in this case, I did mythtv only, not |
| 25 |
world): |
| 26 |
|
| 27 |
These are the packages that would be merged, in order: |
| 28 |
|
| 29 |
Calculating dependencies .... done! |
| 30 |
[ebuild R ~] media-tv/mythtv-0.26.0_p20130121 |
| 31 |
|
| 32 |
|
| 33 |
You can then manually apply the updates. |
| 34 |
|
| 35 |
> |
| 36 |
> But when you "emerge sync" if to do the updates immediately, they'll be |
| 37 |
> the latest packages. If I do a "emerge sync" and wait |
| 38 |
> 7 days to begin updating the packages, I'll be delayed |
| 39 |
> by one week, and have a one week of buffered fixes for added |
| 40 |
> problem filtering. But those fixes might not be available |
| 41 |
> without a fresh "emerge sync"? |
| 42 |
|
| 43 |
Yep, but if you set up an email above, you'll know which versions are |
| 44 |
proposed and you can even search for problems beforehand. Additionally, |
| 45 |
because you now have an email copy of it, you could probably set up |
| 46 |
grep/awk/head/tail/etc to strip out everything but the package prefixed |
| 47 |
with an '=' so it only pulls those packages. This way even if it syncs |
| 48 |
again on its cron, you'll still have a list of packages, but this |
| 49 |
doesn't help if the sync removes existing packages from portage (which |
| 50 |
can happen.) |
| 51 |
|
| 52 |
> |
| 53 |
> |
| 54 |
> When time permits I CAN CHOOSE to "emerge sync" and then immediately |
| 55 |
> update the packages and parse through the issues mostly. Call |
| 56 |
> this the stable-stable approach to gentoo updates. |
| 57 |
|
| 58 |
Yep, but it's still work. Especially if you forgot one week and have to |
| 59 |
update the packages manually. |
| 60 |
|
| 61 |
> I'm increasingly managing more Gentoo systems, particularly embedded |
| 62 |
> and server based gentoo systems and that is the source that compounds these |
| 63 |
> time-sink-issues for me. Maybe some external-integrated management approach |
| 64 |
> such as CFengine is my answer? |
| 65 |
|
| 66 |
CFEngine? I didn't even know what that was until now. I've usually just |
| 67 |
used tools readily available on most installs that didn't require extra |
| 68 |
software. |
| 69 |
|
| 70 |
Dan |
Archives