1 |
El mié, 06-06-2012 a las 14:53 -0400, Mike Frysinger escribió: |
2 |
> On Wednesday 06 June 2012 14:06:47 Pacho Ramos wrote: |
3 |
> > The problem is that grep keeps linked against libpcre and it can cause |
4 |
> > problems like pointed in referred bug report, and it's really risky as |
5 |
> > people can have their portage completely broken for example when libpcre |
6 |
> > is downgraded for some reason. That doesn't sound like a good *default* |
7 |
> > behavior for me |
8 |
> |
9 |
> there are plenty of core tools that can be broken by other packages forcing |
10 |
> broken behavior like library downgrades. |
11 |
|
12 |
I know that, but I am simply trying to get safer values that could help |
13 |
to minimize the risk a bit and, since enabling pcre system wide didn't |
14 |
look (and still don't look) really needed to me, I asked to stop |
15 |
enabling it to prevent this exact risk that looks major enough to me |
16 |
|
17 |
> and FEATURES=preserve-libs would |
18 |
> gracefully handle this. |
19 |
> |
20 |
> off the top of my head, lib dependencies that can bring a system down: |
21 |
> - bash links against ncurses & readline |
22 |
> - sed links against acl |
23 |
> - coreutils links against acl/libcap/selinux/gmp |
24 |
> - grep links against pcre |
25 |
> (with at least USE=acl being a profile default) |
26 |
> |
27 |
> so highlighting the grep/pcre dep doesn't seem like it accomplishes much |
28 |
> -mike |
29 |
|
30 |
I am not trying to reach the safest and unbreakable update path that |
31 |
won't ever fail as explained at top ;) |