Re: [PATCH] dpkg: acquire a read (shared) locks while building packages

[Jan Kiszka <jan.kiszka@siemens.com>]

On 08.03.19 14:33, cedric_hombourger@mentor.com wrote:
> 
> On Friday, March 8, 2019 at 11:04:12 AM UTC+1, Jan Kiszka wrote:
> 
>      > diff --git a/meta/classes/dpkg.bbclass b/meta/classes/dpkg.bbclass
>      > index 24b9fe3..f4e3d7a 100644
>      > --- a/meta/classes/dpkg.bbclass
>      > +++ b/meta/classes/dpkg.bbclass
>      > @@ -19,5 +19,6 @@ do_install_builddeps[stamp-extra-info] =
>     "${DISTRO}-${DISTRO_ARCH}"
>      >   # Build package from sources using build script
>      >   dpkg_runbuild() {
>      >       E="${@ bb.utils.export_proxies(d)}"
>      > +    flock -s "${REPO_ISAR_DIR}/isar.lock" \
>      >       sudo -E chroot --userspec=$( id -u ):$( id -g ) ${BUILDCHROOT_DIR}
>     /isar/build.sh ${PP}/${PPS} ${DISTRO_ARCH}
>      >   }
>      >
> 
>     Couldn't we have the same issue with dpkg-base derived classes? The kernel? Or
>     downstream classes? IOW, shouldn't this go to the caller of dpkg_runbuild?
> 
> 
> I do understand the intent but I don't think we can do something like:
> flock -s <lock-file> dpkg_runbuild
> 
> is there another flock construct we could use to get around this?

Likely true. We would need a construct that bitbake can parse while unrolling 
this function - not aware of any.

> 
> I can update the patch to correct the typo in the commit log
> 

Then let's also patch meta/recipes-kernel/linux/linux-custom.inc analogously and 
leave external dpkg_runbuild to downstream.

Thanks,
Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux