From: Henning Schild <henning.schild@siemens.com>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: <isar-users@googlegroups.com>
Subject: Re: [PATCH] dpkg-base: apt-get "update" before "source"
Date: Tue, 5 Mar 2019 11:11:37 +0100 [thread overview]
Message-ID: <20190305111137.7cfccea1@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <f49f1156-7b6d-7773-4d4c-13676f120e41@siemens.com>
Am Tue, 26 Feb 2019 16:03:42 +0100
schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> On 26.02.19 16:00, Henning Schild wrote:
> > Am Mon, 11 Feb 2019 13:53:07 +0100
> > schrieb Jan Kiszka <jan.kiszka@siemens.com>:
> >
> >> On 11.02.19 10:35, [ext] Henning Schild wrote:
> >>> Here i see an often repeating pattern. That "apt-get update" is
> >>> now present in many entry points to the buildchroot.
> >>> I guess we should factor it out and put it into a central place.
> >>> And the rule of thumb probably is ... whenever you use anything
> >>> apt, apt-get update before you do ...
> >>
> >> If you are only talking about updating our locally maintained repo
> >> (like below), that is fine to factor out and reuse. However, we
> >> must not update against public repos after the initial pulling, in
> >> order to ensure we have a consistent package set along the whole
> >> build.
> >
> > I think that is actually not true. The whole process is an "eventual
> > consistency" topic. Say one of your package compiles for 2
> > weeks ...
>
> Then you will not be able to work. This is no realistic scenario.
Sure, just trying to stress the point that your local view of your
mirror can expire any time. ( 2 weeks or 2 minutes ... )
> > you would never be able to build a buster image. And in fact, no
> > matter how long the time windows is. You can always hit the point
> > where a file that should be there according to your view of the
> > repo, can not be downloaded anymore .... in which case you need to
> > "update/upgrade".
> >
> > So i tend to believe that we should always "apt-get update" without
> > restrictions. For people that truly care about having a
> > reproducible
>
> Nope, we won't do that - unless we have a stable (versioned and
> frozen) repo. This does not apply to upstream Debian, so the current
> pattern is the way to go: single update for a single build.
Several updates would most likely be a noop anyways but ensure that
every "apt-get install" will succeed. We do have the cache and everyone
can have a versioned and frozen repo.
I just started this topic again because Andreas introduced a full
"apt-get update" to deal with the gpg topic.
Henning
> Jan
>
next prev parent reply other threads:[~2019-03-05 10:11 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-11 9:33 Henning Schild
2019-02-11 9:35 ` Henning Schild
2019-02-11 10:50 ` chombourger
2019-02-11 12:53 ` Jan Kiszka
2019-02-11 13:33 ` chombourger
2019-02-18 14:16 ` Maxim Yu. Osipov
2019-02-11 18:08 ` Henning Schild
2019-02-26 15:00 ` Henning Schild
2019-02-26 15:03 ` Jan Kiszka
2019-03-05 10:11 ` Henning Schild [this message]
2019-02-18 22:01 ` 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=20190305111137.7cfccea1@md1za8fc.ad001.siemens.net \
--to=henning.schild@siemens.com \
--cc=isar-users@googlegroups.com \
--cc=jan.kiszka@siemens.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