[gentoo-dev] Suggestion to drop "pcre" from default enabled USE flags in profiles

[gentoo-dev] Suggestion to drop "pcre" from default enabled USE flags in profiles

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

After reading:
https://bugs.gentoo.org/show_bug.cgi?id=419795

I think that would be interesting to try to not get grep build with pcre
support by default, specially after reading "man grep" and seeing that
its support is tagged as experimental:
       -P, --perl-regexp
              Interpret PATTERN as a Perl regular expression.  This is
highly
              experimental and grep -P may warn of unimplemented
features.

Also, at least of my systems there are only a few installed packages
with this USE flag and, then, I am unsure about real advantage of having
it enabled by default :-/

What do you think?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Suggestion to drop "pcre" from default enabled USE flags in profiles

["Paweł Hajdan, Jr."]

[-- Attachment #1: Type: text/plain, Size: 746 bytes --]

On 6/6/12 10:26 AM, Pacho Ramos wrote:
> After reading:
> https://bugs.gentoo.org/show_bug.cgi?id=419795
> 
> I think that would be interesting to try to not get grep build with pcre
> support by default, specially after reading "man grep" and seeing that
> its support is tagged as experimental:

This is more a reason to mask USE=pcre for grep, rather than taking
global action, where pcre may have different meaning or status for other
packages.

> Also, at least of my systems there are only a few installed packages
> with this USE flag and, then, I am unsure about real advantage of having
> it enabled by default :-/

This is a possible reason for dropping it, but I'm not sure. What
exactly uses it and why?

Paweł


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 203 bytes --]

Re: [gentoo-dev] Suggestion to drop "pcre" from default enabled USE flags in profiles

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1396 bytes --]

El mié, 06-06-2012 a las 10:37 +0200, "Paweł Hajdan, Jr." escribió:
> On 6/6/12 10:26 AM, Pacho Ramos wrote:
> > After reading:
> > https://bugs.gentoo.org/show_bug.cgi?id=419795
> > 
> > I think that would be interesting to try to not get grep build with pcre
> > support by default, specially after reading "man grep" and seeing that
> > its support is tagged as experimental:
> 
> This is more a reason to mask USE=pcre for grep, rather than taking
> global action, where pcre may have different meaning or status for other
> packages.
> 

I thought about that option at first time, but later I checked grep
ChangeLog and saw "pcre" USE flag was dropped time ago but later readded
due user request.

> > Also, at least of my systems there are only a few installed packages
> > with this USE flag and, then, I am unsure about real advantage of having
> > it enabled by default :-/
> 
> This is a possible reason for dropping it, but I'm not sure. What
> exactly uses it and why?
> 
> Paweł
> 

In my laptop, just now, only a few:
$ equery hasuse pcre
 * Searching for USE flag pcre ... 
[IP-] [  ] app-admin/syslog-ng-3.2.5:0
[IP-] [  ] dev-lang/swig-2.0.4-r1:0
[IP-] [  ] dev-libs/rasqal-0.9.28:0
[IP-] [  ] sys-apps/grep-2.9:0

but running it with "-p" shows me there are a lot that I don't know if
their support deserves to be enabled by default :(

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Suggestion to drop "pcre" from default enabled USE flags in profiles

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 553 bytes --]

On Wednesday 06 June 2012 04:26:11 Pacho Ramos wrote:
> I think that would be interesting to try to not get grep build with pcre
> support by default, specially after reading "man grep" and seeing that
> its support is tagged as experimental:
>        -P, --perl-regexp
>               Interpret PATTERN as a Perl regular expression.  This is
> highly
>               experimental and grep -P may warn of unimplemented
> features.

the experimental aspect doesn't matter.  don't use -P and it isn't an issue.

personally, i don't care about pcre.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Suggestion to drop "pcre" from default enabled USE flags in profiles

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1137 bytes --]

El mié, 06-06-2012 a las 13:23 -0400, Mike Frysinger escribió:
> On Wednesday 06 June 2012 04:26:11 Pacho Ramos wrote:
> > I think that would be interesting to try to not get grep build with pcre
> > support by default, specially after reading "man grep" and seeing that
> > its support is tagged as experimental:
> >        -P, --perl-regexp
> >               Interpret PATTERN as a Perl regular expression.  This is
> > highly
> >               experimental and grep -P may warn of unimplemented
> > features.
> 
> the experimental aspect doesn't matter.  don't use -P and it isn't an issue.
> 
> personally, i don't care about pcre.
> -mike

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

Of course, other option would be to default to "-pcre" for grep only (by
default), but I don't know if we really want every package to have pcre
by default...


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Suggestion to drop "pcre" from default enabled USE flags in profiles

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 908 bytes --]

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.  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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] Suggestion to drop "pcre" from default enabled USE flags in profiles

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

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 #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]