Isar apt further steps

Isar apt further steps

[Alexander Smirnov]

Hi Henning,

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

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

 >  - add package

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

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

Alex

Re: Isar apt further steps

[Henning Schild]

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

Re: Isar apt further steps

[Henning Schild]

On Wed, 18 Oct 2017 16:00:30 +0200
"[ext] Henning Schild" <henning.schild@siemens.com> wrote:

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

With the "URGENT" kernel changes we now have a situation where next
needs to be rebased anyways, or do you plan to merge?

Henning

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