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