From: Jan Kiszka <jan.kiszka@siemens.com>
To: Alexander Smirnov <asmirnov@ilbers.de>,
isar-users <isar-users@googlegroups.com>
Subject: Re: [PATCH v4 2/8] Prioritize isar-apt repo over all others
Date: Mon, 12 Feb 2018 10:41:17 +0100 [thread overview]
Message-ID: <136df397-5fce-9f50-fd74-f35f038fbda2@siemens.com> (raw)
In-Reply-To: <d61e13c9-97a9-ac13-46c2-8291deb86ab3@ilbers.de>
On 2018-02-12 10:33, Alexander Smirnov wrote:
> On 02/11/2018 06:25 PM, Jan Kiszka wrote:
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>
>> This ensures that we can override packages from upstream Debian or other
>> external sources with our self-built versions. We achieve this for now
>> by asking multistrap to drop a preferences file for the buildchroot so
>> that dependency installations use the right priority. For the image
>> build, this does not work because all packages are pull during the
>> bootstrap. Therefore, we set aptdefaultrelease to isar to ensure that
>> our repo gets the higher priority.
>>
>
> I'm not sure that I completely understand this. What is the use-case for
> this? If you build your own copy of upstream package, this
> prioritization could be resolved by specifying suffix to version.
Simple example: custom kernel build of linux-cip
This generates a package called linux-image-amd64 (for amd64 as target),
and that may have a version < debian's kernel. Now, if we do not
prioritize isar-apt over upstream, the upstream kernel is taken, even
when you switched PREFERRED_PROVIDER (in fact, the build will break when
that virtual package linux-cip is selected but can't be installed due to
the version preference "newest").
>
> For me this approach looks like a good way to have unexpected troubles
> like the following:
>
> 1. You pick current glibc from upstream distro XYZ, let's say v1.0.
> 2. Patch it and put glibc-v1.0-isar to isar-apt.
> 3. Wait for some time until glibc is updated in upstream, let's say to
> v1.1.
> 4. Due to glibc-v1.0-isar is set to be preferred, it's going to be
> installed. But glibc is the core library in distro, and lots of packages
> in XYZ now require glibc-v1.1. So even if you will be able to generate
> image, you can't guarantee it works correctly...
Well, sure, no one takes away the task from you of properly maintaining
the recipes when upstream updates happen (and you pull them into your
reproducible build).
Jan
next prev parent reply other threads:[~2018-02-12 9:41 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-11 15:25 [PATCH v4 0/8] Provide infrastructure and examples for custom kernels and modules Jan Kiszka
2018-02-11 15:25 ` [PATCH v4 1/8] Forward proxy settings to dpkg build Jan Kiszka
2018-02-11 15:25 ` [PATCH v4 2/8] Prioritize isar-apt repo over all others Jan Kiszka
2018-02-12 9:33 ` Alexander Smirnov
2018-02-12 9:41 ` Jan Kiszka [this message]
2018-02-12 10:08 ` Alexander Smirnov
2018-02-12 10:11 ` Jan Kiszka
2018-02-12 10:27 ` Jan Kiszka
2018-02-12 13:09 ` Alexander Smirnov
2018-02-12 13:45 ` Jan Kiszka
2018-02-12 16:31 ` Alexander Smirnov
2018-02-12 17:00 ` Jan Kiszka
2018-02-12 17:27 ` Jan Kiszka
2018-02-12 18:51 ` Alexander Smirnov
2018-02-13 7:22 ` Jan Kiszka
2018-02-13 8:09 ` Alexander Smirnov
2018-02-13 8:22 ` Jan Kiszka
2018-02-13 8:45 ` Alexander Smirnov
2018-02-13 8:51 ` Jan Kiszka
2018-02-11 15:25 ` [PATCH v4 3/8] Replace SRC_DIR with S Jan Kiszka
2018-02-11 15:25 ` [PATCH v4 4/8] Install kernel via replaceable recipe Jan Kiszka
2018-02-11 15:25 ` [PATCH v4 5/8] Provide class for easy custom kernel builds Jan Kiszka
2018-02-12 18:56 ` Alexander Smirnov
2018-02-13 7:03 ` Jan Kiszka
2018-02-13 8:19 ` Alexander Smirnov
2018-02-13 8:24 ` Jan Kiszka
2018-02-13 9:53 ` Henning Schild
2018-02-13 10:21 ` Jan Kiszka
2018-02-11 15:25 ` [PATCH v4 6/8] Add custom kernel examples Jan Kiszka
2018-02-12 19:02 ` Alexander Smirnov
2018-02-13 7:03 ` Jan Kiszka
2018-02-13 8:16 ` Alexander Smirnov
2018-02-13 8:24 ` Jan Kiszka
2018-02-11 15:25 ` [PATCH v4 7/8] Provide include file for easy custom module builds Jan Kiszka
2018-02-11 15:25 ` [PATCH v4 8/8] Add exemplary kernel module Jan Kiszka
2018-02-13 9:41 ` [PATCH v4 0/8] Provide infrastructure and examples for custom kernels and modules Alexander Smirnov
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=136df397-5fce-9f50-fd74-f35f038fbda2@siemens.com \
--to=jan.kiszka@siemens.com \
--cc=asmirnov@ilbers.de \
--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