From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6698318213090902016 X-Received: by 2002:a19:2247:: with SMTP id i68mr61062775lfi.174.1560959841257; Wed, 19 Jun 2019 08:57:21 -0700 (PDT) X-BeenThere: isar-users@googlegroups.com Received: by 2002:ac2:4a67:: with SMTP id q7ls271440lfp.2.gmail; Wed, 19 Jun 2019 08:57:20 -0700 (PDT) X-Google-Smtp-Source: APXvYqxc0lJpHNu27j13ejDN0qy+DsNRC0IwAAhVQcnXNAwWwt/OnGGm2FYibPmW0UgwbCxbXlxX X-Received: by 2002:ac2:4891:: with SMTP id x17mr11925047lfc.60.1560959840798; Wed, 19 Jun 2019 08:57:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560959840; cv=none; d=google.com; s=arc-20160816; b=lc/mZ5iajeCsTH3DA7LR30H+gUJQEoIUFWMOq+5J9ab+q3Z4cFr0PvxKzrLUnWP79C WMUYBx9Ehp827u5fg7U102qV5CfGfxHMNqprY0weFJ3QBUeff0eAgK9TrPKXwfqJhHEn qi/QoJXBu8fIlCueY+zNhD568iJPcB+L8GN7blScpctlr7NxGJpoL4WS7QoXdvyKiu8d L31Ce+B9ojZhQsKla9fV3gMcX8P5jBGB9cytyLeuTiqMwhDMUG1xeh7OYpqxmukMdtvT 3j3WFAy9UOFFpR4JM4hxk5/hddoYwWBqpD1JmYCfOOKHqQhqk+8Ni7zQGL0wjZnXCUTW OYYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=user-agent:in-reply-to:content-disposition:mime-version:references :mail-followup-to:message-id:subject:to:from:date; bh=kP4CFTXrOZNxi4YYhjOh5dNW1SUrKWHFLKA84kvkJwU=; b=PgJRIf0jEYURlAtfPhW7O0BeJJVdXvULdiqyEzxiU3mP+ad0iqBIsQjMecUoU1aj/P Cot5zyaeyXE1wiJOq3DJLexDYcLcyRME9J5MkgxjoyuBKQhI74P/vYtPDycCJ0HQyt1P BvQGl4ZYN8wEygutm8IGj8FBgmq5D3nsQDMGtt+84r0/lL8jP2SpUd8L2qtbPpPh/mF6 YweaPgde+bgOD+aBTEoPX4r8/3zZiN0/piPINF8B2kjUA7Oqwn28JFXc8BlTiK6DgMZM E1JIVwPgcF8xf+c+x0ZkOl5RJ+qKUsgJNZn9A2xrJfihPfalI9gRsKyfwYq5RHEQX2SF kDxg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id h1si850073ljm.3.2019.06.19.08.57.20 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 19 Jun 2019 08:57:20 -0700 (PDT) Received-SPF: neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 85.214.156.166 is neither permitted nor denied by best guess record for domain of ibr@radix50.net) smtp.mailfrom=ibr@radix50.net Received: from yssyq.m.ilbers.de (host-80-81-17-52.static.customer.m-online.net [80.81.17.52]) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id x5JFvIqA030223 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 19 Jun 2019 17:57:19 +0200 Date: Wed, 19 Jun 2019 17:57:18 +0200 From: Baurzhan Ismagulov To: isar-users Subject: Re: TODOs Message-ID: <20190619155718.GZ3977@yssyq.m.ilbers.de> Mail-Followup-To: isar-users References: <9345ebb3-983b-06b5-0a32-572a595d9d5c@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9345ebb3-983b-06b5-0a32-572a595d9d5c@siemens.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: 0bKhh70pBPD6 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.