| 1 |
On 15.02.2013 00:58, Daniel Frey wrote: |
| 2 |
> On 02/14/2013 11:26 AM, James wrote: |
| 3 |
>> Hello, |
| 4 |
>> |
| 5 |
>> Context: Stable Systems with a few newer packages |
| 6 |
>> (unmasked) in portage. |
| 7 |
>> |
| 8 |
> --snip-- |
| 9 |
>> |
| 10 |
>> So, my latest ideas is to "sync up" and then wait one week |
| 11 |
>> before acutally installing those new packages. This would |
| 12 |
>> allow the fodder that the good folks on this list catch, |
| 13 |
>> bitch about (um, I mean file bug reports) and fix, to |
| 14 |
>> occur first; then I can complete the package update |
| 15 |
>> cautiously avoiding an "emerge sync". |
| 16 |
> |
| 17 |
> I suppose you could set up a weekly cron job (say on a Saturday) to do |
| 18 |
> something like: |
| 19 |
> |
| 20 |
> emerge -fuDN world > proposed_change.txt |
| 21 |
|
| 22 |
AFAICT, if you do not really do an emerge --sync, this command will |
| 23 |
repeatedly show nothing. |
| 24 |
|
| 25 |
> Then a few days later (say Wednesday?) email that file to yourself so |
| 26 |
> you know what changes are being proposed. |
| 27 |
|
| 28 |
You surely know, there is a great toolset, eix, which has eix-sync |
| 29 |
command that does emerge --sync and shows all updated ebuilds. |
| 30 |
But anyway, to update a package, you'll have to sync. |
| 31 |
|
| 32 |
>> When time permits I CAN CHOOSE to "emerge sync" and then immediately |
| 33 |
>> update the packages and parse through the issues mostly. Call |
| 34 |
>> this the stable-stable approach to gentoo updates. |
| 35 |
|
| 36 |
IMHO that is not a solution: rather, a solution is not to update world |
| 37 |
but pick single packages to update. Most software does not *require* an |
| 38 |
update, unless there are security/stability issues. So doing a world |
| 39 |
update to track such issues is kinda hunting sparrows with a mortar. |
| 40 |
And practical experience has it that "it works, and don't touch it". |
| 41 |
Pretty often some unnecessary update causes an unnecessary mess, even if |
| 42 |
the dev guys put it as stable. |
| 43 |
|
| 44 |
A delay after emerge --sync is pretty useless because you end up with a |
| 45 |
(week-)old portage tree, so to fix any possible bugs found that week, |
| 46 |
you'd do another sync so... you see. |
| 47 |
|
| 48 |
For the purpose of stability, I don't see an alternative to doing emerge |
| 49 |
--sync but singling out packages to update rather than updating world. |
| 50 |
|
| 51 |
In the real world, there's no 100% secure way to be 100% secure, you |
| 52 |
know. You just choose the path you deem more suitable based on risk/work |
| 53 |
and efficiency/work relations. |
| 54 |
|
| 55 |
|
| 56 |
|
| 57 |
-- |
| 58 |
Best wishes, |
| 59 |
Yuri K. Shatroff |
Archives