public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Baurzhan Ismagulov <ibr@radix50.net>
To: isar-users <isar-users@googlegroups.com>
Subject: Re: TODOs
Date: Wed, 19 Jun 2019 17:57:18 +0200	[thread overview]
Message-ID: <20190619155718.GZ3977@yssyq.m.ilbers.de> (raw)
In-Reply-To: <9345ebb3-983b-06b5-0a32-572a595d9d5c@siemens.com>

Hello Claudius,

thanks for sharing.

On Mon, Jun 03, 2019 at 04:55:39PM +0200, Claudius Heine wrote:
> here is a list of TODOs for isar that I gathered:
> 
> - WIC_IMAGER_DEPENDS should be IMAGER_DEPENDS instead

Is it a new var, or do you by chance mean WIC_IMAGER_INSTALL and
IMAGER_INSTALL?


> - IMAGE_INSTALL, IMAGE_PREINSTALL, DEPENDS refactoring so that it is
> possible to provide recipes that produce multiple packages. Currently all
> entries in IMAGE_INSTALL are added to DEPENDS, but DEPENDS should only
> contain recipe names and IMAGE_INSTALL only package names.

This is tightly coupled with the subject of handling Debian packages with
bitbake, which we have been experimenting with in meta-eid. We had started with
the dependencies. One limitation is that bitbake parses all recipes, then
builds the dependency tree. Debian packages may be local or remote, so they
have to be fetched before the dependency tree is built.

For now, the workaround is to duplicate Build-Depends: in DEPENDS.

Do I understand your use case correctly, you have a.bb producing aa.deb and
ab.deb. You want to have IMAGE_INSTALL += "ab" instead of "a", do you? If yes,
can this be workarounded with PROVIDES = "aa ab"? As I see it, the final
solution without duplication would require solving Debian package handling in
some way.


> - base-apt refactoring/redesign:
>   - multiple distros/codenames in one base-apt repo. base-apt repos should
> be build specific not specific to distros/codenames.

I see that this is desirable for certain use cases. That said, it might also be
a matter of downstream policy, so that either choice is poorly suited for some
other downstreams. Ideally, I'd like to have it configurable.


>   - no manual switch via `ISAR_USE_CACHED_REPO`. The cache should be build
> and used at every build

This can be enabled downstream. This is also a matter of policy: Some projects
always work with the latest stuff, some make snapshots. The ability to turn it
off is useful as a reference if anything breaks.


> - redesign fstab generation:
>   - make it more flexible
>   - usable with or without wic and init system independent
> - isar-bootstrap refactoring:
>   - remove duplicate code
>   - split up big functions to allow
>   - inc file should be class
>   - separate host/target bootstrap settings
>   - host/target/build nomenclature fix

I agree that the inconsistencies exist. The main reason is that compiler people
have to name it differently from the 99% of application developers who
intuitively understand the right thing from "host" and "target". So I'm still
not sure whether the change is worth it.


> - refactor RootFS size calculation, make it similar to the formula of open
> embedded:
>     root_fs_partition_size = max(used_space * overhead_factor,
> fixed_rootfs_size) + extra_space
>     where overhead_factor, fixed_rootfs_size and extra_space is user
> configurable
>     overhead_factor is the IMAGE_OVERHEAD_FACTOR bb variable
>     fixed_rootfs_size is IMAGE_ROOTFS_SIZE bb variable
>     extra_space is IMAGE_ROOTFS_EXTRA_SPACE bb variable
>     all of them in Kbytes
> - integration solution for on-first-boot resize rootfs.
>   -> investigate systemd-first-boot and systemd-growfs


With kind regards,
Baurzhan.

  reply	other threads:[~2019-06-19 15:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-03 14:55 TODOs Claudius Heine
2019-06-19 15:57 ` Baurzhan Ismagulov [this message]
2019-06-24 11:48   ` TODOs Claudius Heine

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190619155718.GZ3977@yssyq.m.ilbers.de \
    --to=ibr@radix50.net \
    --cc=isar-users@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox