| 1 |
On Tue, 16 Sep 2008, Stroller wrote: |
| 2 |
> |
| 3 |
> The risk is that you want to install X that depends upon Y. |
| 4 |
> |
| 5 |
> The ebuild for X states that version >1.2.3 of Y must be used because |
| 6 |
> there's a bug in 1.2.2. |
| 7 |
> |
| 8 |
> The new version of Y fails to compile, so when X is compiled it only |
| 9 |
> has the old version of Y to work with. It may compile OK but not work |
| 10 |
> or feature a security bug. |
| 11 |
|
| 12 |
That's not the real risk: Since any sane user will of course check which |
| 13 |
packages have failed and make sure that the upgraded version will be |
| 14 |
installed, this will not leave you with an inconsistent system |
| 15 |
(the next emerge -NaDu world - which of course also any sane user would |
| 16 |
do afterwards - would even tell you the problem, and in case of an ABI |
| 17 |
change you would be informed by revdep-rebuild). |
| 18 |
The only case I can think of where _really_ problems might arise is the |
| 19 |
(very rare) situation which I had described: That the ./configure script |
| 20 |
of X builds X without errors but also without support for Y if only 1.2.2 |
| 21 |
of Y is installed: |
| 22 |
Then neither later upgrading of Y nor revdep-rebuild will show anything |
| 23 |
suspicious, although X does not behave in the intended way. |
Archives