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: Wed, 26 Oct 2022 09:17:35 +0200 [thread overview]
Message-ID: <a1ef7cf9-f64a-c214-91b9-a454c052cd4b@siemens.com> (raw)
In-Reply-To: <2564476.vYhyI6sBWr@hp>
On 26.10.22 09:06, Uladzimir Bely wrote:
> In mail from вторник, 25 октября 2022 г. 16:37:51 +03 user Jan Kiszka wrote:
>> 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.
>
> It seems sbuild man pages say nothing about "--allow-downgrades". So, I'm not
> sure if it's used.
>
> Anyway, now I guess that setting `--no-apt-upgrade` and `--no-apt-distupgrade`
> in the v1 of patch is wrong. Most probably, such configuration won't allow
> even upgrades from debian packages to isar-apt ones.
>
> Also, you are saying, "isar-apt has higher prior than other repo". Where is it
> configured? I thought, `isar-apt` is just one of sources from "apt" and if
> Debian has newer package version than we compiled by hand, these newer
> dependencies are to be installed...
https://github.com/ilbers/isar/blob/18db2a59f22ec3c376a1518627250d14683338fa/meta/classes/rootfs.bbclass#L93
Jan
--
Siemens AG, Technology
Competence Center Embedded Linux
prev parent reply other threads:[~2022-10-26 7:17 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
2022-10-26 7:06 ` Uladzimir Bely
2022-10-26 7:17 ` Jan Kiszka [this message]
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=a1ef7cf9-f64a-c214-91b9-a454c052cd4b@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