public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: "Schmidt, Adriaan" <adriaan.schmidt@siemens.com>
To: Baurzhan Ismagulov <ibr@radix50.net>,
	"isar-users@googlegroups.com" <isar-users@googlegroups.com>
Subject: RE: [RFC PATCH] Remove isar-apt and the corresponding lock
Date: Mon, 12 Dec 2022 12:36:47 +0000	[thread overview]
Message-ID: <AS4PR10MB531893A26303DACD795589A5EDE29@AS4PR10MB5318.EURPRD10.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <Y1JxMJ+h6arOc0/P@ilbers.de>

Baurzhan Ismagulov, Freitag, 21. Oktober 2022 12:15:
> On Wed, Oct 19, 2022 at 12:47:45PM +0200, Adriaan Schmidt wrote:
> > In addition to removing the lock, this also gives us better control
> > over what goes into a package build, and eliminates effects due to
> "accidental"
> > packages in isar-apt.
> 
> We are aware of this issue. isar-apt is the "Debian way" deliverable from an
> Isar-based project, containing the locally-built packages. To implement
> proper
> Debian Build-Depends functionality (without duplicating DEPENDS on bitbake
> level), we need the respective introspection of which packages come from
> Debian
> and which ones are built locally. For this, we need to enhance base-apt and
> isar-apt (and maybe bitbake or some new class) to enable such introspection.
> [1] and [2] are the beginning of this work (they don't cover all of it
> today).

I don't see a conflict here. I'd say the .deb introspection and more advanced
detection of dependencies is an independent issue.

> We've looked at the locking in scope of [2]. We know that isar-apt critical
> section is too coarse and can be greatly narrowed down. If this is the pain
> point, we could prioritize that specific issue and provide the respective
> improvement. We'll check your patch in more detail, but I'm against removing
> isar-apt altogether.

I see the value of isar-apt as a deliverable of a build. But I don't think
it's the best tool to transfer packages during build. To transfer between
recipes of the same build, this RFC could be an alternative. And to transfer
to other builds (re-use packages to speed things up), we have sstate. 
I had a look at [2], and one problem I see is that packages are only identified
by their filename and version, and this does not lead to a rebuild when
any of the inputs (sources, recipe) change.

If we remove isar-apt as a tool to transfer packages during build, I would
definitely bring it back, possibly as a feature of the rootfs or image class
(e.g., bitbake my-image -c export-apt-repo).

Adriaan

> 1. base-apt enhancement: https://patchwork.isar-
> build.org/project/isar/patch/20220325103226.27033-1-ubely@ilbers.de/
> 2. isar-apt enhancement: https://patchwork.isar-
> build.org/project/isar/patch/20220613070759.16949-1-ubely@ilbers.de/
> 
> With kind regards,
> Baurzhan
> 


  reply	other threads:[~2022-12-12 12:36 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-19 10:47 Adriaan Schmidt
2022-10-21  8:02 ` Raphael Lisicki
2022-10-21 10:15 ` Baurzhan Ismagulov
2022-12-12 12:36   ` Schmidt, Adriaan [this message]
2022-12-13  3:44     ` Moessbauer, Felix
2022-12-13  9:13       ` Baurzhan Ismagulov

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=AS4PR10MB531893A26303DACD795589A5EDE29@AS4PR10MB5318.EURPRD10.PROD.OUTLOOK.COM \
    --to=adriaan.schmidt@siemens.com \
    --cc=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