-
Bug
-
Resolution: Fixed
-
Critical (Application)
-
None
-
None
-
None
-
The only reason why not many people have noticed this is because they have libpcre2 installed before they install grep for some reason, but if you rely only on the grep ebuild, this blocks install.
-
Grep has moved from libpcre to libpcre2 for Perl Regexp support.
I'm not sure about the real issue and if it's only a Macaroni generator issue.
What I found is this:
# luet database get sys-apps/grep annotations: subsets: rules: devel: - ^/usr/include/ portage: - ^/var/db/pkg/ buildtimestamp: 2022-10-22 16:32:44.193064254 +0000 UTC m=+31.383540699 category: sys-apps conflicts: null description: GNU regular expression matcher id: 28 labels: BDEPEND: app-arch/xz-utils virtual/pkgconfig nls? ( sys-devel/gettext ) DEPEND: '!static? ( pcre? ( >=dev-libs/libpcre-7.8-r1 ) ) nls? ( virtual/libintl ) virtual/libiconv static? ( pcre? ( >=dev-libs/libpcre-7.8-r1[static-libs(+)] ) )' IUSE: nls pcre static RDEPEND: '!static? ( pcre? ( >=dev-libs/libpcre-7.8-r1 ) ) nls? ( virtual/libintl ) virtual/libiconv' emerge.packages: sys-apps/grep kit: core-kit original.package.name: sys-apps/grep original.package.slot: "0" original.package.version: "3.8" license: GPL-3
The RDEPEND/DEPEND when `pcre` is enable depend on libpcre but testing the Macaroni images I have this:
t4 / # ldd /bin/grep linux-vdso.so.1 (0x00007ffe4654a000) libpcre2-8.so.0 => not found libc.so.6 => /lib/libc.so.6 (0x00007f2a2c7eb000) /lib64/ld-linux-x86-64.so.2 (0x00007f2a2c9f6000)
The libpcre2-8.so.o is owned by dev-libs/libpcre2 package.
So the question is: Could be correct for grep-3.8 change libpcre with libpcre2?
- relates to
-
-
- Closed
-