Bug#907651: grep: dlopens libpcre, but is directly linked to it anyway
Control: tags -1 + pending El 17/11/18 a las 02:06, Michael Biebl escribió: > On Fri, 26 Oct 2018 10:31:08 +0200 Laurent Bigonville > wrote: > > Hello, > > > > Wasn't the initial idea of this patch to be able to have libpcre on > > /usr/lib and grep on /bin? https://savannah.gnu.org/patch/?7017#comment0 > > seems to confirm that. > > > > And now that libpcre is in installed in /lib, the patch has probably > > lost his meaning. > > Also keep in mind, that late-mounting of /usr is no longer supported. > /usr needs to be on the same partition as / or mounted via the > initramfs, so this patch has become obsolete. Good point, thanks. Patch removed in the git repository. Cheers, S signature.asc Description: PGP signature
Bug#907651: grep: dlopens libpcre, but is directly linked to it anyway
On Fri, 26 Oct 2018 10:31:08 +0200 Laurent Bigonville wrote: > Hello, > > Wasn't the initial idea of this patch to be able to have libpcre on > /usr/lib and grep on /bin? https://savannah.gnu.org/patch/?7017#comment0 > seems to confirm that. > > And now that libpcre is in installed in /lib, the patch has probably > lost his meaning. Also keep in mind, that late-mounting of /usr is no longer supported. /usr needs to be on the same partition as / or mounted via the initramfs, so this patch has become obsolete. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#907651: grep: dlopens libpcre, but is directly linked to it anyway
El 26/10/18 a las 10:31, Laurent Bigonville escribió: > Hello, > > Wasn't the initial idea of this patch to be able to have libpcre on /usr/lib > and grep on /bin? https://savannah.gnu.org/patch/?7017#comment0 seems to > confirm that. > > And now that libpcre is in installed in /lib, the patch has probably lost > his meaning. Yes, indeed. > Note also that libpcre3 is currently[1] pulled by libselinux1 anyway so > it's pulled on all systems. I haven't taken the time to check if there are other Essential packages depending on libpcre3. But this is a good point to choose removing the patch in debian. > > Kind regards, > > Laurent Bigonville > > [1] This might change in the future, as it also supports libpcre2 > Thanks for your message. Cheers, Santiago signature.asc Description: PGP signature
Bug#907651: grep: dlopens libpcre, but is directly linked to it anyway
Hello, Wasn't the initial idea of this patch to be able to have libpcre on /usr/lib and grep on /bin? https://savannah.gnu.org/patch/?7017#comment0 seems to confirm that. And now that libpcre is in installed in /lib, the patch has probably lost his meaning. Note also that libpcre3 is currently[1] pulled by libselinux1 anyway so it's pulled on all systems. Kind regards, Laurent Bigonville [1] This might change in the future, as it also supports libpcre2
Bug#907651: grep: dlopens libpcre, but is directly linked to it anyway
Hi Simon, El 30/08/18 a las 18:54, Simon McVittie escribió: > Package: grep > Version: 3.1-2 > Severity: normal > > The version of grep in Debian carries a patch to dlopen libpcre.so.3. > However, it is also directly linked to libpcre.so.3 (objdump -Tx /bin/grep > shows "NEEDED libpcre.so.3"), and will not execute without it. This also > generates a hard dependency (in fact a Pre-Depends, because grep is > Essential: yes). Thanks for spotting and reporting this. And sorry for this delayed answer. > > If the intention was to make grep -P opportunistically use libpcre.so.3 > if present, but not use it if absent (like the way libopenal1 has a weak > dependency on libasound2, libpulse0 and libportaudio2), then it should > not be linked with -lpcre, only with -ldl. This will need some sort of > patch to its build system. > > Alternatively, if grep -P is considered to be part of the Essential > functionality of grep, then the dlopen patch can be dropped and it can > just use libpcre like a normal library (the same as pcregrep). > > Please choose one or the other: the current situation is the worst of > both worlds (you have the maintenance headache of the patch, but you > still have the dependency). Well, *I* don't consider -P as an essential functionality of grep. But on the other side, declaring the normal dependency would make the things simpler (and the simpler the better). I still prefer a weak dependency, but it's not up to me to decide. Aníbal, any thoughts? > The changelog entry for 2.25-6 suggests that a weak dependency > is what was intended. If so, then it should be possible for the > upstream-test-suite-no-pcre3 autopkgtest to be reinstated and pass > without libpcre3 installed. It would probably be also good to have an > autopkgtest that runs "objdump -Tx /bin/grep | grep NEEDED" and > asserts that libpcre is not in the output. Yes, that makes sense. Thanks, -- Santiago signature.asc Description: PGP signature
Bug#907651: grep: dlopens libpcre, but is directly linked to it anyway
Package: grep Version: 3.1-2 Severity: normal The version of grep in Debian carries a patch to dlopen libpcre.so.3. However, it is also directly linked to libpcre.so.3 (objdump -Tx /bin/grep shows "NEEDED libpcre.so.3"), and will not execute without it. This also generates a hard dependency (in fact a Pre-Depends, because grep is Essential: yes). If the intention was to make grep -P opportunistically use libpcre.so.3 if present, but not use it if absent (like the way libopenal1 has a weak dependency on libasound2, libpulse0 and libportaudio2), then it should not be linked with -lpcre, only with -ldl. This will need some sort of patch to its build system. Alternatively, if grep -P is considered to be part of the Essential functionality of grep, then the dlopen patch can be dropped and it can just use libpcre like a normal library (the same as pcregrep). Please choose one or the other: the current situation is the worst of both worlds (you have the maintenance headache of the patch, but you still have the dependency). The changelog entry for 2.25-6 suggests that a weak dependency is what was intended. If so, then it should be possible for the upstream-test-suite-no-pcre3 autopkgtest to be reinstated and pass without libpcre3 installed. It would probably be also good to have an autopkgtest that runs "objdump -Tx /bin/grep | grep NEEDED" and asserts that libpcre is not in the output. smcv
