From: Henning Schild <henning.schild@siemens.com>
To: vijai kumar <vijaikumar.kanagarajan@gmail.com>
Cc: isar-users <isar-users@googlegroups.com>,
Vijai Kumar K <Vijaikumar_Kanagarajan@mentor.com>
Subject: Re: [PATCH v4 2/2] meta: cache deb srcs as part of postprocessing
Date: Wed, 15 Apr 2020 20:19:57 +0200 [thread overview]
Message-ID: <20200415201957.66ec3eed@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <CALLGG_+qawggJT4GG92HUuxZH5jyDny+r2o0J-_vADXksbkffQ@mail.gmail.com>
On Wed, 15 Apr 2020 17:59:12 +0530
vijai kumar <vijaikumar.kanagarajan@gmail.com> wrote:
> On Wed, Apr 8, 2020 at 6:00 PM Henning Schild
> <henning.schild@siemens.com> wrote:
> >
> > Am Wed, 8 Apr 2020 16:07:15 +0530
> > schrieb vijai kumar <vijaikumar.kanagarajan@gmail.com>:
> >
> > > On Wed, Apr 8, 2020 at 3:34 PM Henning Schild
> > > <henning.schild@siemens.com> wrote:
> > > >
> > > > Am Fri, 3 Apr 2020 18:35:51 +0530
> > > > schrieb Vijai Kumar K <vijaikumar.kanagarajan@gmail.com>:
> > > >
> > > > > Collect the deb sources of the corresponding deb binaries
> > > > > cached in DEBDIR as part of postprocess for those to be later
> > > > > included into the final base-apt by do_cache.
> > > > >
> > > > > Signed-off-by: Vijai Kumar K
> > > > > <Vijaikumar_Kanagarajan@mentor.com> ---
> > > > > meta/classes/image.bbclass | 2 +-
> > > > > meta/classes/rootfs.bbclass | 46
> > > > > +++++++++++++++++++++++++++++++++++++ 2 files changed, 47
> > > > > insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/meta/classes/image.bbclass
> > > > > b/meta/classes/image.bbclass index 9fa58f8..1c7a527 100644
> > > > > --- a/meta/classes/image.bbclass
> > > > > +++ b/meta/classes/image.bbclass
> > > > > @@ -60,7 +60,7 @@ image_do_mounts() {
> > > > > }
> > > > >
> > > > > ROOTFSDIR = "${IMAGE_ROOTFS}"
> > > > > -ROOTFS_FEATURES += "copy-package-cache clean-package-cache
> > > > > generate-manifest" +ROOTFS_FEATURES += "copy-package-cache
> > > > > clean-package-cache generate-manifest cache-deb-src"
> > > > > ROOTFS_PACKAGES += "${IMAGE_PREINSTALL} ${IMAGE_INSTALL}"
> > > > > ROOTFS_MANIFEST_DEPLOY_DIR ?= "${DEPLOY_DIR_IMAGE}"
> > > > > diff --git a/meta/classes/rootfs.bbclass
> > > > > b/meta/classes/rootfs.bbclass index 8bb003d..7bfdfc9 100644
> > > > > --- a/meta/classes/rootfs.bbclass
> > > > > +++ b/meta/classes/rootfs.bbclass
> > > > > @@ -201,6 +201,52 @@ rootfs_generate_manifest () {
> > > > > ${ROOTFS_MANIFEST_DEPLOY_DIR}/"${PF}".manifest
> > > > > }
> > > > >
> > > > > +ROOTFS_POSTPROCESS_COMMAND +=
> > > > > "${@bb.utils.contains('ROOTFS_FEATURES', 'cache-deb-src',
> > > > > 'cache_deb_src', '', d)}" +cache_deb_src() {
> > > > > + if [ "${ISAR_USE_CACHED_BASE_REPO}" = "1" ]; then
> > > > > + return 0
> > > > > + fi
> > > >
> > > > Should the source packages not all end up in the cache, so they
> > > > can and probably should be fetched from there.
> > >
> > > Sorry. But I am not able to understand this. Can you please
> > > explain it again?
> >
> > A first build without the cache will fetch all sources and drop them
> > into "${DEBSRCDIR}"/"${DISTRO}", just the the apt:// fetcher does.
> > A second build with an enabled cache will place all those src-pkgs
> > in base-apt (see populate_base_apt repo_add_srcpackage loop).
> >
> > So a second run of this function here should be able to fetch all
> > those srcs-pkgs from base-apt. And it would be a good idea to
> > actually do that to prove that everything is available offline.
> >
> > Note that for real offline BB_NO_NETWORK would be required. And that
> > "guard" should still be able to download from base-apt. Thinking
> > about it again ... i think you do not need the guard. If all
> > src-pkgs are available offline this function will never access the
> > internet, if it still tries the invalid proxy "guard" from
> > isar_export_proxies will trigger.
> >
> > I think it boils down to removing the
> > [ "${ISAR_USE_CACHED_BASE_REPO}" = "1" ] && exit 0
> > and passing the ci offline/cache test
> >
> > > >
> > > > > + mkdir -p "${DEBSRCDIR}"/"${DISTRO}"
> > > > > +
> > > > > + sudo -s <<'EOSUDO'
> > > > > + cp -L /etc/resolv.conf '${ROOTFSDIR}/etc'
> > > > > + mkdir -p '${ROOTFSDIR}/deb-src'
> > > > > + mountpoint -q '${ROOTFSDIR}/deb-src' || \
> > > > > + mount --bind '${DEBSRCDIR}' '${ROOTFSDIR}/deb-src'
> > > > > +EOSUDO
> > > > > +
> > > > > + sudo -E chroot ${ROOTFSDIR} /usr/bin/apt-get update
> >
> > Why is that in here? Doing this in the image is not allowed, only
> > for isar-apt!
>
> Hi Henning,
>
> I am sorry. But why is it not allowed? Am I missing any side effects
> of this call?
Thanks for asking, please keep doing that when things are unclear.
An "update" stores a copy of the "view on the repo world" in the image.
It is essentially a copy of the Packages.gz or Sources.gz of all repos.
That information changes over time on the servers, while they still
(hopefully) offer to download packages referenced in older version of
those indexes.
Isar relies on that. It fetches all indexes exactly once and later
downloads packages found in the cached versions. Once you update an
index the "view of the world" moves away from "the state of the image".
On a living debian system you would always upgrade packages after
update-ing the indexes. In an "installer" - like Isar - you probably do
not want those dynamics.
So in order to keep "the state of the image" and "the view of the
world" in sync we never "apt-get update" ... except for isar-apt which
is a repo we can/do control.
If a build takes a really long time, there is a slim chance that we can
not actually fetch packages found in our old indexes because upstream
does not provide them anymore. I have not seen real evidence of that
potential problem. It could however manifest if we have a long running
build ... arm without cross ... and do additional fetches in postinst
... like you are implementing.
But whatever you can not fetch in the end, is probably not worth
fetching because it is not what was used to construct your image.
Henning
> Thanks,
> Vijai Kumar K
>
> >
> > > > > + find "${DEBDIR}"/"${DISTRO}" -name '*\.deb' | while read
> > > > > package; do
> >
> > You are reading this without grabbing the lock. In multiconfig other
> > images might be filling that directory as you read it. And you
> > might be calling dpkg-deb on half copied files.
> >
> > Try deb_dl_dir_import and looping over /var/cache/apt/archives/ ...
> > in which case you will find yourself dealing with isar-apt packages
> > that you need to skip.
> > In fact you should use the manifest as input to not download
> > packages installed in other images with the same distro but without
> > the feature.
> >
> > Yeahh multiconfig!
> >
> > Henning
> >
> > > > > + local src="$( dpkg-deb --show --showformat
> > > > > '${Source}' "${package}" )"
> > > > > + # If the binary package version and source package
> > > > > version are different, then the
> > > > > + # source package version will be present inside "()"
> > > > > of the Source field.
> > > > > + local version="$( echo "$src" | cut -sd "(" -f2 |
> > > > > cut -sd ")" -f1 )"
> > > > > + if [ -z ${version} ]; then
> > > > > + version="$( dpkg-deb --show --showformat
> > > > > '${Version}' "${package}" )"
> > > > > + fi
> > > > > + # Now strip any version information that might be
> > > > > available.
> > > > > + src="$( echo "$src" | cut -d' ' -f1 )"
> > > > > + # If there is no source field, then the source
> > > > > package has the same name as the
> > > > > + # binary package.
> > > > > + if [ -z "${src}" ];then
> > > > > + src="$( dpkg-deb --show --showformat '${Package}'
> > > > > "${package}" )"
> > > > > + fi
> > > > > +
> > > > > + sudo -E chroot --userspec=$( id -u ):$( id -g )
> > > > > ${ROOTFSDIR} \
> > > > > + sh -c 'mkdir -p "/deb-src/${1}/${2}" && cd
> > > > > "/deb-src/${1}/${2}" && \
> > > > > + apt-get -y --download-only --only-source
> > > > > source "$2"="$3"' \
> > > > > + download-src "${DISTRO}" "${src}"
> > > > > "${version}"
> > > > > + done
> > > >
> > > > Looks like we are going online without proxy configuration
> > > > here. It also needs a BB_NO_NETWORK guard.
> > >
> > > Will take care of that.
> > >
> > > >
> > > > And i would suggest to generate the list of things you want to
> > > > fetch, factor out the fetcher from dpkg-base and reuse is
> > > > instead of copying it.
> > >
> > > Sure. I will have a look into how I can reuse that part.
> > >
> > > >
> > > > And i would personally like a new series of patches to be sent
> > > > without "in-reply-to". Maybe its my client but i find these
> > > > deeply nested threads very hard to follow.
> > >
> > > No Problem. Will send the next series separately.
> > >
> > > Thanks,
> > > Vijai Kumar K
> > >
> > > >
> > > > Henning
> > > >
> > > > > + sudo -s <<'EOSUDO'
> > > > > + mountpoint -q '${ROOTFSDIR}/deb-src' && \
> > > > > + umount -l ${ROOTFSDIR}/deb-src
> > > > > + rm -rf '${ROOTFSDIR}/etc/resolv.conf'
> > > > > +EOSUDO
> > > > > +}
> > > > > +
> > > > > do_rootfs_postprocess[vardeps] =
> > > > > "${ROOTFS_POSTPROCESS_COMMAND}" python
> > > > > do_rootfs_postprocess() { # Take care that its correctly
> > > > > mounted:
> > > >
> >
next prev parent reply other threads:[~2020-04-15 18:20 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 14:06 [PATCH] rootfs: Make rootfs_postprocess_finalize the last step Vijai Kumar K
2020-02-06 17:21 ` Jan Kiszka
2020-02-06 17:47 ` vijai kumar
2020-02-06 18:09 ` Jan Kiszka
2020-02-06 18:28 ` vijai kumar
2020-02-10 5:37 ` [PATCH v2] rootfs: Make rootfs finalize a separate task Vijai Kumar K
2020-02-11 11:38 ` Henning Schild
2020-02-11 14:14 ` vijai kumar
2020-02-11 15:20 ` Henning Schild
2020-02-11 18:07 ` Jan Kiszka
2020-02-13 10:08 ` [PATCH v2 1/2] " Vijai Kumar K
2020-02-13 10:08 ` [PATCH v2 2/2] meta: cache deb srcs as part of postprocessing Vijai Kumar K
2020-02-14 5:48 ` [PATCH v3 1/2] rootfs: Make rootfs finalize a separate task Vijai Kumar K
2020-02-14 5:48 ` [PATCH v3 2/2] meta: cache deb srcs as part of postprocessing Vijai Kumar K
2020-02-14 8:19 ` Jan Kiszka
2020-02-14 8:41 ` vijai kumar
2020-02-14 8:45 ` vijai kumar
2020-03-11 7:16 ` [PATCH v3 1/2] rootfs: Make rootfs finalize a separate task vijai kumar
2020-04-01 7:25 ` vijai kumar
2020-04-01 8:19 ` Henning Schild
2020-04-01 10:29 ` vijai kumar
2020-04-03 6:50 ` vijai kumar
2020-04-03 8:30 ` Baurzhan Ismagulov
2020-04-03 8:50 ` vijai kumar
2020-04-03 13:05 ` [PATCH v4 " Vijai Kumar K
2020-04-03 13:05 ` [PATCH v4 2/2] meta: cache deb srcs as part of postprocessing Vijai Kumar K
2020-04-07 6:44 ` Jan Kiszka
2020-04-07 6:58 ` vijai kumar
2020-04-07 7:04 ` Jan Kiszka
2020-04-07 7:59 ` vijai kumar
2020-04-07 8:38 ` Jan Kiszka
2020-04-07 9:08 ` vijai kumar
2020-04-07 9:40 ` vijai kumar
2020-04-08 8:13 ` Baurzhan Ismagulov
2020-04-08 10:04 ` vijai kumar
2020-04-08 13:32 ` vijai kumar
2020-04-15 6:44 ` vijai kumar
2020-04-15 7:28 ` Jan Kiszka
2020-04-15 13:20 ` vijai kumar
2020-04-15 13:44 ` Jan Kiszka
2020-04-08 10:04 ` Henning Schild
2020-04-08 10:37 ` vijai kumar
2020-04-08 12:30 ` Henning Schild
2020-04-15 12:29 ` vijai kumar
2020-04-15 18:19 ` Henning Schild [this message]
2020-04-16 15:57 ` vijai kumar
2020-04-16 17:29 ` Henning Schild
2020-04-07 6:19 ` [PATCH v3 1/2] rootfs: Make rootfs finalize a separate task vijai kumar
2020-04-07 6:45 ` Jan Kiszka
2020-04-07 6:53 ` vijai kumar
2020-04-07 7:12 ` Baurzhan Ismagulov
2020-04-07 8:04 ` vijai kumar
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=20200415201957.66ec3eed@md1za8fc.ad001.siemens.net \
--to=henning.schild@siemens.com \
--cc=Vijaikumar_Kanagarajan@mentor.com \
--cc=isar-users@googlegroups.com \
--cc=vijaikumar.kanagarajan@gmail.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