Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Gentoo: Dev

Suggestion to drop "pcre" from default enabled USE flags in profiles

 

 

Gentoo dev RSS feed   Index | Next | Previous | View Threaded


pacho at gentoo

Jun 6, 2012, 1:26 AM

Post #1 of 7 (257 views)
Permalink
Suggestion to drop "pcre" from default enabled USE flags in profiles

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?
Attachments: signature.asc (0.19 KB)


phajdan.jr at gentoo

Jun 6, 2012, 1:37 AM

Post #2 of 7 (254 views)
Permalink
Re: Suggestion to drop "pcre" from default enabled USE flags in profiles [In reply to]

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ł
Attachments: signature.asc (0.20 KB)


pacho at gentoo

Jun 6, 2012, 1:52 AM

Post #3 of 7 (253 views)
Permalink
Re: Suggestion to drop "pcre" from default enabled USE flags in profiles [In reply to]

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 :(
Attachments: signature.asc (0.19 KB)


vapier at gentoo

Jun 6, 2012, 10:23 AM

Post #4 of 7 (246 views)
Permalink
Re: Suggestion to drop "pcre" from default enabled USE flags in profiles [In reply to]

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
Attachments: signature.asc (0.82 KB)


pacho at gentoo

Jun 6, 2012, 11:06 AM

Post #5 of 7 (243 views)
Permalink
Re: Suggestion to drop "pcre" from default enabled USE flags in profiles [In reply to]

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...
Attachments: signature.asc (0.19 KB)


vapier at gentoo

Jun 6, 2012, 11:53 AM

Post #6 of 7 (247 views)
Permalink
Re: Suggestion to drop "pcre" from default enabled USE flags in profiles [In reply to]

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
Attachments: signature.asc (0.82 KB)


pacho at gentoo

Jun 6, 2012, 12:18 PM

Post #7 of 7 (247 views)
Permalink
Re: Suggestion to drop "pcre" from default enabled USE flags in profiles [In reply to]

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 ;)
Attachments: signature.asc (0.19 KB)

Gentoo dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.