From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6665957031077216256 X-Received: by 2002:a7b:c0c8:: with SMTP id s8mr1415108wmh.6.1552058861162; Fri, 08 Mar 2019 07:27:41 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:adf:f4c3:: with SMTP id h3ls1276153wrp.3.gmail; Fri, 08 Mar 2019 07:27:40 -0800 (PST) X-Google-Smtp-Source: APXvYqxtpwtP+hDwo4obzO7SypcvVioZdjyd8sMTkvfkbDv9iwyyPSokDehy2+pYpCF2fLR7Nthw X-Received: by 2002:adf:c748:: with SMTP id b8mr1047754wrh.4.1552058860622; Fri, 08 Mar 2019 07:27:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1552058860; cv=none; d=google.com; s=arc-20160816; b=B3zViZGnN96vzwEqqKC76WY177WZG99Y9Wm90kuDg9MmyTGf2mJY2N7gE3g9DxtfzG pmZFcO+bHb3BF1USUDEipUtUQtjqpSZpnwUwmQyk70qhJW8ohOzZ77Ai39+JYCJpi4oX KSX8cShrxAhmaPv+wx+wm8jUoRh2Hck8XyUC/HQSmi61D6TYzRCihiVNiAIi/XJW2Kwh Y010hDteNdhyRBC8yIbxV/OfhmAIMYE7UxsdA15zYWWQxHYXZFrdqFBtyOf8dETIbo7M bp3+DyFvyPg+TdXTeiWI7TPX0x5jWZSFAKIplUdZxjrZXYxFl4wqvO2QMiDV54tBalKx JaCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:from:references:to:subject; bh=tMpaCfc5FKvrG+vBpTvhYpAdnH9IfwHvhvEw3nm5+zI=; b=01TR2JiVX4nZhOPOhn4GLRLc36IyjrPdGKe7vF2tQldz9zXLWGBqUp0Hq/qzSbrBGf WCp41vheAf337RQNluFAddWAK6DcCaBK+RMO985CGby0hRky1VUnUKecfqcumJ13BGit WDbPeOFbwfAsdZkUTK1ajeqSrPcFjZ7z3GhOeNtfDSHGi/Ba9dVKL08tXt4v0h5cKIR9 E4SzViHXS79/DADulSmkQt+IfSi77UXTAnaXzHaU9CGklXpPCDJrfHztknNCl8G5Kkfi 12q+uEicLIgtsglOOKzRKMo91PPY5GJMrGLhmuddz4sOax4R2znmqaLcACaGo5uda99U 9r9g== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id b130si322262wmc.0.2019.03.08.07.27.40 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Mar 2019 07:27:40 -0800 (PST) Received-SPF: pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of jan.kiszka@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=jan.kiszka@siemens.com Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id x28FRen1004732 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 8 Mar 2019 16:27:40 +0100 Received: from [139.25.68.37] (md1q0hnc.ad001.siemens.net [139.25.68.37] (may be forged)) by mail2.sbs.de (8.15.2/8.15.2) with ESMTP id x28FResV022635; Fri, 8 Mar 2019 16:27:40 +0100 Subject: Re: [PATCH] dpkg: acquire a read (shared) locks while building packages To: cedric_hombourger@mentor.com, isar-users 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> <6cd427c7-087d-44e5-9dcc-082b97eeb0bb@googlegroups.com> From: Jan Kiszka Message-ID: <97148d8a-edea-f4c3-d35d-f538512b7c38@siemens.com> Date: Fri, 8 Mar 2019 16:27:39 +0100 User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666 MIME-Version: 1.0 In-Reply-To: <6cd427c7-087d-44e5-9dcc-082b97eeb0bb@googlegroups.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TUID: Pg9Q4ouqfhYV On 08.03.19 16:24, cedric_hombourger@mentor.com wrote: > 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 :) Indeed, then we are safe at this point. If you sent v2, please add this reason to the changelog. Hopefully, the person will read that who adds kernel tool packaging via debhelpers one day. ;) Thanks, Jan -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux