public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Uladzimir Bely <ubely@ilbers.de>, isar-users@googlegroups.com
Subject: Re: [PATCH] sbuild: Don't update apt database on every package build
Date: Tue, 25 Oct 2022 15:37:51 +0200	[thread overview]
Message-ID: <08331fcb-e592-8ee1-70c7-072932657528@siemens.com> (raw)
In-Reply-To: <6810893.9J7NaK4W3v@hp>

On 25.10.22 11:00, Uladzimir Bely wrote:
> In mail from понедельник, 24 октября 2022 г. 17:14:52 +03 user Jan Kiszka 
> wrote:
>> On 24.10.22 15:10, Uladzimir Bely wrote:
>>> By default, sbuild updates apt database beforethe build. It may cause
>>> an inconsistency between apt databases for different packages built at
>>> the different time if external (Debian) mirrors has updated recently.
>>>
>>> With new changes, sbuild will rely on global apt state that was got
>>> during debootstrap stage.
>>>
>>> Local `isar-apt` repo will still be automatically updated while it is
>>> passed via `--extra-repository=` argument.
>>
>> Will that also ensure upgrades, e.g. from essential debian packages to
>> self-built ones hosted in isar-apt? We had a few of such cases in the
>> past already in downstream layers, and I recall permitting upgrades to
>> the old buildchroot for that.
>>
> 
> I'm afraid I don't exactly get you question... 
> 
> Do you mean, it may happen that Isay may update 'isar-apt' repository, but
> won't even try to install "newer" (custom) package from isar-apt as an upgrade 
> of some Debian package installed at debootstrap stage?

Actually, part of my former problems were downgrades, not upgrades, see
[1] and [2]. Those are possible as well because anything coming from
isar-apt has higher prior than other repo. Now I was only wondering if
that behavior is still given, with all those switches applied and
schroot in between us and the actual apt calls.

> 
> Yes, probably it may happen. The case I tried to cover is just to make sbuild 
> know about custom packages in 'isar-apt' so it could install them as depends.
> But if the package already installed (e.g. at debootstrap or sbuild-chroot 
> stage) it may happen it won't be upgraded.
> 
> I guess, there should be someting like "--no-apt-update --apt-distupgrade" 
> then. So, apt database won't be updated, but if 'isar-apt' provides new 
> version of already installed (Debian) package, it will be used.
> 
> Or, even "--no-apt-update" should be enough, while "$apt_distupgrade" is 
> already set by default in sbuild...
> 
> 
> Additinally, it would be good to have some test for this case. For example, we 
> could have "hello" (from Debian) preinstalled before build, but upgrade it to 
> custom "patched" version during sbuild.
> 

Yes, that would indeed be good.

Jan

[1]
https://github.com/ilbers/isar/commit/5367ba74d9f2f0b82560bab6c146f0521e13049f
[2]
https://github.com/ilbers/isar/commit/77e62c1e9bbda107a10136d1aa5f26f5f6660371

-- 
Siemens AG, Technology
Competence Center Embedded Linux


  reply	other threads:[~2022-10-25 13:37 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-24 13:10 Uladzimir Bely
2022-10-24 14:14 ` Jan Kiszka
2022-10-25  9:00   ` Uladzimir Bely
2022-10-25 13:37     ` Jan Kiszka [this message]
2022-10-26  7:06       ` Uladzimir Bely
2022-10-26  7:17         ` Jan Kiszka

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=08331fcb-e592-8ee1-70c7-072932657528@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=isar-users@googlegroups.com \
    --cc=ubely@ilbers.de \
    /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