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

["Storm, Christian (CT RDA ITP SES-DE)" <christian.storm@siemens.com>]

> > >> 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.

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.


   Christian

-- 
Dr. Christian Storm
Siemens AG, Corporate Technology, CT RDA ITP SES-DE
Otto-Hahn-Ring 6, 81739 M�nchen, Germany