Re: [PATCH v3 1/3] dpkg: move installation of dependencies into dpkg_prepare

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

On 2018-08-31 10:41, Jan Kiszka wrote:
> On 2018-08-31 10:33, chombourger@gmail.com wrote:
>>
>>
>> On Friday, August 31, 2018 at 10:28:51 AM UTC+2, Jan Kiszka wrote:
>>
>>     Re-reading the patch with my new knowledge:
>>
>>     On 2018-08-26 08:21, Cedric Hombourger wrote:
>>      > diff --git a/meta/recipes-kernel/linux-module/module.inc
>>     b/meta/recipes-kernel/linux-module/module.inc
>>      > index 3075f44..3a3cab1 100644
>>      > --- a/meta/recipes-kernel/linux-module/module.inc
>>      > +++ b/meta/recipes-kernel/linux-module/module.inc
>>      > @@ -17,7 +17,7 @@ AUTOLOAD ?= "0"
>>      >
>>      >   inherit dpkg
>>      >
>>      > -dpkg_runbuild_prepend() {
>>      > +do_prepare_prepend() {
>>
>>     Shouldn't that be dpgk_prepare_append()?
>>
>>
>> Wouldn't it be too late?
>> I am afraid that debian/control wouldn't be complete and prevent 
>> installation of build dependencies
>>
> 
> Right, we need that for the installation...
> 
> I was wondering, though, if it wouldn't be cleaner to hook additions to 
> the inner handler.
> 
> Anyway, all this is not mature yet:
> 
> - debianization does not require locking, only the dependency
>    installation does
> 
> - I'm quite sure something is broken now with dpkg-raw, because there is
>    no lock involved, but we can pull packages that way as well
> 

Yep, confirmed: We so far installed the dependencies of both regular and 
raw packages in the build script under the lock. Now you pulled that 
installation into deps.sh, but that script is not executed by dpkg-raw, 
nor is there any lock on the related prepare step.

Can we fix this quickly? Or better revert and redo the series (given the 
other issues)?

Jan

> - we should cleanly name the steps, as you suggested, so that users know
>    what to overwrite / append /prepend
> 
> Jan
> 

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