| 1 |
I am total Gentoo newb :D but it seems kind of fundamental to the |
| 2 |
concept of this distribution that its users are going to make |
| 3 |
themselves aware of the details of system updates. Short of reading |
| 4 |
ridiculous amounts of doco...folks should be reading the output of the |
| 5 |
emerge commands to learn about edge cases like this one. |
| 6 |
|
| 7 |
In the short few days I've been using Gentoo, there have been several |
| 8 |
occasions where had I not read that output, my system would have been |
| 9 |
'broken' on next reboot. At the very least there were additional |
| 10 |
steps needed for me to install that package I tried to emerge (missing |
| 11 |
USE flags, requests to rebuild other packages, external data |
| 12 |
downloads, etc.). |
| 13 |
|
| 14 |
Personally, I rather like this approach. The folks maintaining the |
| 15 |
builds take the time to identify these edge cases, which makes the |
| 16 |
portage text output quite helpful. |
| 17 |
|
| 18 |
-- |
| 19 |
Matt |
| 20 |
|
| 21 |
On Thu, Jan 1, 2009 at 1:09 PM, b.n. <brullonulla@×××××.com> wrote: |
| 22 |
> Volker Armin Hemmann ha scritto: |
| 23 |
>> On Donnerstag 01 Januar 2009, Michael P. Soulier wrote: |
| 24 |
>>> On 01/01/09 Volker Armin Hemmann said: |
| 25 |
>>>> after the emerge you read the messages with elogv and downgrade. No harm |
| 26 |
>>>> done. |
| 27 |
>>> I'll be sure to try that, thank you. However, would not avoiding a bad |
| 28 |
>>> upgrade in the first place be a better-behaved tool? Especially when the |
| 29 |
>>> package in question "knew" that it was likely incompatible? |
| 30 |
>>> |
| 31 |
>>> I'm not saying that this could not be avoided with more work, I'm saying |
| 32 |
>>> that I shouldn't have to if the tools were better behaved. |
| 33 |
>>> |
| 34 |
>>> Cheers, |
| 35 |
>>> Mike |
| 36 |
>> |
| 37 |
>> how should 'the tool' know what card you are using? |
| 38 |
> |
| 39 |
> The tool knew -in fact it told him of the breakage , *after* doing it. |
| 40 |
> |
| 41 |
>> and even if portage could |
| 42 |
>> parse lspci output - why make it slower and more easily to break if all |
| 43 |
>> breakage can be avoided by simply reading first - then upgrading? |
| 44 |
> |
| 45 |
> If you don't know there's something to read... |
| 46 |
> |
| 47 |
>> Do you |
| 48 |
>> always install the latest drivers without reading up on them first? |
| 49 |
> |
| 50 |
> Usually, yes. Could be my fault, but am I expected to read technical |
| 51 |
> docs everytime I update a package? |
| 52 |
> Anyway, the system *knows* that there's a problem, so your point is |
| 53 |
> moot. The only thing we're asking is to warn and stop *before* and not |
| 54 |
> *after*. |
| 55 |
> |
| 56 |
>> Nvidia's 'deprecation' strategy is a pain in the ass and they are doing it for |
| 57 |
>> a long time now. So this time it bit you. Next time it will be 6XXX card |
| 58 |
>> users, then 7XXX card users and so on. That is why you have to go to nvnews |
| 59 |
>> first and then upgrade. Not the other way round. |
| 60 |
> |
| 61 |
> Thanks for advice. |
| 62 |
> |
| 63 |
> m. |
| 64 |
> |
| 65 |
> |
| 66 |
> |
| 67 |
> |
| 68 |
> |
Archives