From: Henning Schild <henning.schild@siemens.com>
To: Jan Kiszka <jan.kiszka@web.de>
Cc: isar-users <isar-users@googlegroups.com>
Subject: Re: [PATCH] buildchroot: Perform upgrade after build dependency installation
Date: Wed, 23 Jan 2019 16:29:04 +0100 [thread overview]
Message-ID: <20190123162904.12c9ba1b@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <bb01c145-fa10-d3db-fb9f-fd30aa5d631a@web.de>
Am Tue, 22 Jan 2019 19:19:58 +0100
schrieb Jan Kiszka <jan.kiszka@web.de>:
> On 22.01.19 18:08, Henning Schild wrote:
> > Am Tue, 22 Jan 2019 17:22:14 +0100
> > schrieb Jan Kiszka <jan.kiszka@web.de>:
> >
> >> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>
> >> When we partially rebuild after updating the version of a build
> >> dependency of another package, we do not properly upgrade that
> >> dependency in buildchroot. The reason is that "apt-get install"
> >> performs upgrades only for the explicitly listed packages. But we
> >> install build dependencies indirectly, we a meta package's
> >> dependency.
> >>
> >> Resolve that be running an explicit "apt-get upgrade" after the
> >> build dependency installation. This will ensure pulling the latest
> >> versions for isar-apt.
> >
> > I am not sure i fully understand the problem given your description,
> > but i get the idea.
> >
> > The mk-build-deps calls an apt-get that will not do anything even if
> > builddep-0.1 has to be updated to builddep-0.2? Maybe you can
> > address
>
> If you refer with "builddep" to the meta package that mk-build-dep is
> generating
> - no, it's one of the indirect dependencies it refers to. Concrete
> case: kernel update, and kernel-headers will not be upgraded, thus
> the module built against the wrong kernel.
No i am talking about the package at the lower end. We have A -> B ->
C0 + C1 + C2. A is the one we want to build, B is the artificial
package, and Cxx are the ones on the "lower end".
> > the problem with the "-t" argument of mk-build-dep?
>
> I've tried various switched to apt-get install, but it just reported
> to not do the identified upgrades. I would prefer a magic switch as
> well, so I'm all ears which one we may miss.
Did the debian version string change to something greater? If not it
should probably increase.
Another option would be to "apt-get remove" a packages from all
buildchroots on its clean, unless it was explicitly installed.
But i guess what you came up with is fine as well, and less
complicated.
Henning
> Jan
next prev parent reply other threads:[~2019-01-23 15:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-22 16:22 Jan Kiszka
2019-01-22 17:08 ` Henning Schild
2019-01-22 18:19 ` Jan Kiszka
2019-01-23 15:29 ` Henning Schild [this message]
2019-01-30 11:49 ` Maxim Yu. Osipov
2019-01-30 13:17 ` Jan Kiszka
2019-02-05 17:20 ` Maxim Yu. Osipov
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=20190123162904.12c9ba1b@md1za8fc.ad001.siemens.net \
--to=henning.schild@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=jan.kiszka@web.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