| 1 |
On Wed, May 1, 2013 at 11:22 AM, Ciaran McCreesh |
| 2 |
<ciaran.mccreesh@××××××××××.com> wrote: |
| 3 |
> ...and that it's utterly frickin' broken as a concept, and that |
| 4 |
> adopting it will slow down people switching to the proper solution to |
| 5 |
> the problem, which is slots. |
| 6 |
|
| 7 |
Unless we fully slot (not subslot) every version of everything that |
| 8 |
gets linked there is still the issue of what happens between the time |
| 9 |
package A is upgraded, and package B which depends on A is upgraded. |
| 10 |
That will often be minutes, and could be hours or days even with slot |
| 11 |
operator dependencies. Some packages take a long time to build, and |
| 12 |
if there is a failure it might take a user days to work it out. |
| 13 |
|
| 14 |
Even if preserve-libs is imperfect, it improves usability. Are there |
| 15 |
any scenarios where it actually makes things worse? Sure, maybe once |
| 16 |
in a blue moon a lib no longer works because it is out of sync with a |
| 17 |
config file, but would it work any better if it were just outright |
| 18 |
deleted? |
| 19 |
|
| 20 |
Rich |
Archives