1 |
On Sun, 2005-05-15 at 17:18 -0400, Mike Frysinger wrote: |
2 |
> one advantage that other binary based package managers have over Gentoo is |
3 |
> ease of recovery from broken core packages ... break your gcc ? no problem ! |
4 |
> simply do `apt-get install gcc` or `rpm -i gcc` or whatever |
5 |
> |
6 |
> my proposal is to implement a new utility (called 'erescue' for lack of a |
7 |
> better name) that is written in C and designed to be statically linked ... |
8 |
> then next time you break a core system package which cannot be recovered by |
9 |
> simply running `emerge` a few times, you run `erescue <broken package>` |
10 |
> |
11 |
> for example, when i broke binutils in unstable with a gcc4 patch, i noticed |
12 |
> that it's hard for users to *easily* recover from this ... we developers end |
13 |
> up scrambling to build a bunch of binary packages for a variety of compatible |
14 |
> compiler/libc combinations so the user can just wget the file and run `emerge |
15 |
> binutils.tbz2` and be on their way |
16 |
> |
17 |
> the packages that would be eligible for an 'erescue' package would be just |
18 |
> about everything when you do `USE=-* emerge system -ep` ... i'm sure we can |
19 |
> trim many of those out though :) maybe even create a new USE flag for some |
20 |
> of these core packages so that we can trim out more files |
21 |
> |
22 |
> the idea would be to create very bare min packages so that the user can simply |
23 |
> 'rescue' themselves ... after that, they it's up to them to re-emerge the |
24 |
> package to apply all their fun ricer-optimizations as they see fit |
25 |
> |
26 |
> i dont think it'd be too hard to integrate this 'rescue set' into a catalyst |
27 |
> target so that it'll become part of our normal release schedule of stage |
28 |
> tarballs |
29 |
> -mike |
30 |
|
31 |
This would really help me at work, as I generally have to partimage my |
32 |
workstation PC before updates that might break stuff. |
33 |
|
34 |
I nominate "ecockup-reverse" as the name. |
35 |
|
36 |
-- |
37 |
Tom Wesley <tom@×××××.org> |