Re: Isar apt further steps

[Henning Schild <henning.schild@siemens.com>]

On Wed, 18 Oct 2017 14:05:01 +0300
Alexander Smirnov <asmirnov@ilbers.de> wrote:

> Hi Henning,
> 
> I'd like to start separate discussion about further apt steps because 
> previous series was applied before your last comment:

As i just wrote you in the original thread, please remove these
patches, they are not ready to get merged and are on a rebasing branch.

>  > - create one task in dpkg-base.bbclass that does the following
>  >  - config and init reprepro if no other recipe did that before  
> 
> Hmm, in general repository generation should be performed only once, 
> moreover in most cases it should be done for dedicated Isar image, 
> otherwise no need to cache binaries to apt if it's not used. So
> that's why I've put repo creation to image class.

If there is a way to express "image step to run before any package
recipe starts". I guess all recipes "do_populate_apt" need a [depends]
"image:do_cache_config"

>  >  - add package  
> 
> If task[lockfile] works for multiconfig, then I definitely like this 
> approach.

I certainly hope so. If not, you know my opinion on multiconfig ;).

>  >  - use bitkages task[lockfiles] to deal with races between recipes,
>  >    put distro into lockfile-name so we have one lock per distro
>  > - drop do_populate  
> 
> That's already in todo, the blocking issue was locking mechanism for 
> multiconfig.
> 
>  > - call the new task instead of, or in do_deploy_deb  
> 
> 
> 
> 
> So, to summarize my vision:
> 
> 1. image.bbclass: do_cache_config(). Use [lockfiles] = ${DISTRO} to 
> handle multiconfig and 'bitbake image-A image-B' parallel builds.
> 
> 2. dpkg-base.bbclass: do_populate_apt(). Use [lockfiles] = ${DISTRO}
> to avoid races between recipes and for multiconfig.
> 
> 3. Drop image.bbclass: do_populate()
> 
> 4. Remove ${DEPLOY_DIR_DEB} from Isar.
> 
> What do you think?

Sounds good!

Henning
 
> Alex