Note: Due to technical difficulties, the Archives are currently not up to date.
GMANE provides an alternative service for most mailing lists. c.f. bug 424647
List Archive: gentoo-dev
El mié, 06-06-2012 a las 14:53 -0400, Mike Frysinger escribió:
> On Wednesday 06 June 2012 14:06:47 Pacho Ramos wrote:
> > The problem is that grep keeps linked against libpcre and it can cause
> > problems like pointed in referred bug report, and it's really risky as
> > people can have their portage completely broken for example when libpcre
> > is downgraded for some reason. That doesn't sound like a good *default*
> > behavior for me
>
> there are plenty of core tools that can be broken by other packages forcing
> broken behavior like library downgrades.
I know that, but I am simply trying to get safer values that could help
to minimize the risk a bit and, since enabling pcre system wide didn't
look (and still don't look) really needed to me, I asked to stop
enabling it to prevent this exact risk that looks major enough to me
> and FEATURES=preserve-libs would
> gracefully handle this.
>
> off the top of my head, lib dependencies that can bring a system down:
> - bash links against ncurses & readline
> - sed links against acl
> - coreutils links against acl/libcap/selinux/gmp
> - grep links against pcre
> (with at least USE=acl being a profile default)
>
> so highlighting the grep/pcre dep doesn't seem like it accomplishes much
> -mike
I am not trying to reach the safest and unbreakable update path that
won't ever fail as explained at top ;)
|
| Attachment: |
|
signature.asc (This is a digitally signed message part)
|
|