From mboxrd@z Thu Jan  1 00:00:00 1970
X-GM-THRID: 6665957031077216256
Date: Fri, 8 Mar 2019 07:24:30 -0800 (PST)
From: cedric_hombourger@mentor.com
To: isar-users <isar-users@googlegroups.com>
Message-Id: <6cd427c7-087d-44e5-9dcc-082b97eeb0bb@googlegroups.com>
In-Reply-To: <a90bcb21-d11c-368e-173a-4004375e8860@siemens.com>
References: <1552039053-1152-1-git-send-email-Cedric_Hombourger@mentor.com>
 <473ab398-0c28-00d9-5dd2-8caafb7dbf5f@siemens.com>
 <35924a2e-5207-453e-afa3-609478c5b4e1@googlegroups.com>
 <a90bcb21-d11c-368e-173a-4004375e8860@siemens.com>
Subject: Re: [PATCH] dpkg: acquire a read (shared) locks while building
 packages
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_1306_2094112272.1552058670819"
X-Google-Token: EK6SiuQFZillBxbIJ3Y0
X-Google-IP: 95.176.90.117
X-TUID: OvhZHvhg2oKN

------=_Part_1306_2094112272.1552058670819
Content-Type: multipart/alternative; 
	boundary="----=_Part_1307_966299298.1552058670820"

------=_Part_1307_966299298.1552058670820
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


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

it should be noted that "make dpkg-deb" does not use debhelper (as I 
recently found while modifying the kernel builddep script to also package 
perf and
wondering why my shlibs variables were not parsed)

So, to the best of my knowledge, the current (mainline) package scripts 
from the kernel will not access the dpkg database. so are we wanting to be
extra safe and grab a shared lock anyway (which will block other bitbake 
threads from running do_install_deps or do_deploy_deb while the kernel
builds since bitbake grabs an exclusive lock for these tasks) OR use this 
"knowledge" to keep some parallelism.

I am fine either way - just wanted to expose both options :)

Cedric 

------=_Part_1307_966299298.1552058670820
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Then let&#39;=
s also patch meta/recipes-kernel/linux/<wbr>linux-custom.inc analogously an=
d=20
<br>leave external dpkg_runbuild to downstream.
<br></blockquote><div><br></div><div>it should be noted that &quot;make dpk=
g-deb&quot; does not use debhelper (as I recently found while modifying the=
 kernel builddep script to also package perf and</div><div>wondering why my=
 shlibs variables were not parsed)</div><div><br></div><div>So, to the best=
 of my knowledge, the current (mainline) package scripts from the kernel wi=
ll not access the dpkg database. so are we wanting to be</div><div>extra sa=
fe and grab a shared lock anyway (which will block other bitbake threads fr=
om running do_install_deps or do_deploy_deb while the kernel</div><div>buil=
ds since bitbake grabs an exclusive lock for these tasks) OR use this &quot=
;knowledge&quot; to keep some parallelism.</div><div><br></div><div>I am fi=
ne either way - just wanted to expose both options :)</div><div><br></div><=
div>Cedric=C2=A0</div></div>
------=_Part_1307_966299298.1552058670820--

------=_Part_1306_2094112272.1552058670819--