Message ID | 20241023173911.1411724-1-danismostlikely@gmail.com |
---|---|
State | New |
Headers | show |
Series | ppp: make pam optional to avoid host contamination | expand |
On 23 Oct 2024, at 18:39, Dan McGregor via lists.openembedded.org <danismostlikely=gmail.com@lists.openembedded.org> wrote: > This is a somewhat difficult to hit, only my test machines that have > the pam dev package installed show it. That’s exactly the reproducer with host contaimination problems. > +PACKAGECONFIG ??= "" > +PACKAGECONFIG[pam] = "--with-pam=yes,--with-pam=no,libpam” We have a ‘pam’ DISTRO_FEATURE, should we just respect that as the default PACKAGECONFIG using bb.utils.filter? Ross
On Thu, 24 Oct 2024 at 13:01, Ross Burton via lists.openembedded.org <ross.burton=arm.com@lists.openembedded.org> wrote: > > +PACKAGECONFIG ??= "" > > +PACKAGECONFIG[pam] = "--with-pam=yes,--with-pam=no,libpam” > > We have a ‘pam’ DISTRO_FEATURE, should we just respect that as the default PACKAGECONFIG using bb.utils.filter? Only if the host contamination is tracked down and solved? Otherwise this should not be an option, but rather a hard disable with a comment on how to reproduce. Alex
> On 24 Oct 2024, at 12:14, Alexander Kanavin <alex.kanavin@gmail.com> wrote: > > On Thu, 24 Oct 2024 at 13:01, Ross Burton via lists.openembedded.org > <ross.burton=arm.com@lists.openembedded.org> wrote: >>> +PACKAGECONFIG ??= "" >>> +PACKAGECONFIG[pam] = "--with-pam=yes,--with-pam=no,libpam” >> >> We have a ‘pam’ DISTRO_FEATURE, should we just respect that as the default PACKAGECONFIG using bb.utils.filter? > > Only if the host contamination is tracked down and solved? Otherwise > this should not be an option, but rather a hard disable with a comment > on how to reproduce. Well, if there’s no pam in distro features then it is explicitly turned off, and if there is pam in distro features then we have a libpam in DEPENDS. The failure path is in https://github.com/ppp-project/ppp/blob/master/m4/ax_check_pam.m4, yet again autoconf-archive has some pretty terrible logic. It looks like if it can find libpam with pkg-config then it won’t try and hunt around /usr, which is where the contamination comes from. As long as we either explicitly disable or enable-with-DEPENDS, there is no contamination. Ross
diff --git a/meta/recipes-connectivity/ppp/ppp_2.5.1.bb b/meta/recipes-connectivity/ppp/ppp_2.5.1.bb index 5b8c49ca850..19e89b18383 100644 --- a/meta/recipes-connectivity/ppp/ppp_2.5.1.bb +++ b/meta/recipes-connectivity/ppp/ppp_2.5.1.bb @@ -27,7 +27,10 @@ SRC_URI = "https://download.samba.org/pub/${BPN}/${BP}.tar.gz \ SRC_URI[sha256sum] = "733b7f5840b613da4eab0429a5081293275f06ba8b528e1b8eea6964faf0243a" -inherit autotools systemd +inherit autotools systemd pkgconfig + +PACKAGECONFIG ??= "" +PACKAGECONFIG[pam] = "--with-pam=yes,--with-pam=no,libpam" EXTRA_OECONF += "--with-openssl=${STAGING_EXECPREFIXDIR}"