Re: [PATCH 3/4 v2] buildchroot: Add prepare and cleanup tasks

[Alexander Smirnov <asmirnov@ilbers.de>]

On 12/11/2017 04:37 PM, Storm, Christian (CT RDA ITP SES-DE) wrote:
>>>>> 2. 'do_cleanup': This task is executed after all the packages are
>>>>> deployed. Some notes:
>>>>>    - This task also should not have stamp.
>>>>>    - This task depends from the recipes listed in IMAGE_INSTALL.
>>>>
>>>> This breaks build dependencies when building two packages from
>>>> source (same example I've given in other posts as well):
>>>>
>>>> Consider A-dev required by B, both to be built from source. B cannot
>>>> install the A-dev.deb since B depending on A-dev's deploy_deb() and
>>>> installing it the ugly way via dpkg -i (as no other option is
>>>> currently available in Isar) puts B as late in the task order so
>>>> that it's git repo is not mounted anymore. Failure.
>>>>
>>>> If A-dev installs it's produced .deb as last step in its
>>>> dpkg_runbuild(), which is also ugly, then there's a potential race
>>>> in dpkg. Failure.
>>>
>>> Seems I don't fully understand your usecase, could you please comment
>>> if it's correct:
>>>
>>> 1. You have two Isar recipes A and B that build packages from source
>>> code.
>>>
>>> 2. After building of package A, apart from binary A, A-dev also
>>> provided.
>>>
>>> 3. Package B depends on A-dev.
>>>
>>> Also, have you added dependency from A in B recipe?
>>
>> Dependencies will not help here, Isar simply does not support that
>> case ... yet.
>> You have B depending on A both at runtime and on build-time. So you need
>> a buildchroot to build A in. And for B you need a buildchroot which has
>> A installed.
>>
>> To get the buildchroot for B you either have to install A into its own
>> buildchroot or multistrap again.
>>
>> I think Christian currently installs A, but with "dpkg -i". I think
>> multistrapping again would be overkill. IMHO the best solution would be
>> to install such packages in buildchroot with apt-get, after they have
>> been repreproed to the "Isar" repo.
> 
> Yes, right, ugly, I know, but currently the only way to reflect my use
> case -- which Henning described very well -- in Isar. Without this hack
> or preferably a proper solution to this, I cannot use Isar for my use
> case. Since this change, in fact, I can't.
> 

Sorry, but I still don't understand how this patch brakes your build 
because it doesn't influence on dependencies at all. If you need strict 
order for packages to be built, then anyway you have to specify this in 
recipe:

In recipe B:

DEPENDS += "A"
do_build[deptask] = "do_build"

It would be very helpful for me if you could provide recipes and workaround.

> So, in some sense I relied on a workaround for a missing feature that's
> now broken and hence you may rightfully argue that nothing can break a
> missing feature. Nonetheless, it did so for me and my hack :)
> 
> 
>> I suggested improvements on "[PATCH 0/4 v5] Isar apt deployment" but
>> the feedback was delayed until a v2.
>>
>> Essentially deploy_deb needs to reprepro, do_populate needs to go away,
>> builchroot needs aptsources=Isar in its multistrap.conf. Now the
>> apt-get in build.sh should work.
> 
> I very much appreciate a proper solution to this to resume using Isar
> for my use case.

Could handle this after your top-prio issues.

Alex