From: Henning Schild <henning.schild@siemens.com>
To: Uladzimir Bely <ubely@ilbers.de>
Cc: isar-users@googlegroups.com
Subject: Re: [PATCH v2 3/3] Changes for a faster build using less disk space
Date: Fri, 6 Jan 2023 16:58:26 +0100 [thread overview]
Message-ID: <20230106165826.1346da94@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <20230106064809.10412-4-ubely@ilbers.de>
Am Fri, 6 Jan 2023 07:48:09 +0100
schrieb Uladzimir Bely <ubely@ilbers.de>:
> From: "Roberto A. Foglietta" <roberto.foglietta@gmail.com>
>
> Faster build for larger projects with a lot of debian packages
>
> This patch leverages few ways to accomplish the task to optimise
> the large buildings.
>
> Put a CACHEDIR.TAG file in each cache folder in such a way every
> tar that uses the option --exclude-caches could be avoided
> to include debian packages saving a lot of time and disk space.
>
> Signed-off-by: Roberto A. Foglietta <roberto.foglietta@gmail.com>
> Signed-off-by: Uladzimir Bely <ubely@ilbers.de>
> ---
> meta/classes/deb-dl-dir.bbclass | 2 +-
> meta/classes/rootfs.bbclass | 3 ++-
> meta/recipes-core/isar-bootstrap/isar-bootstrap.inc | 7 ++++++-
> 3 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/meta/classes/deb-dl-dir.bbclass
> b/meta/classes/deb-dl-dir.bbclass index 7db25251..3afad4e8 100644
> --- a/meta/classes/deb-dl-dir.bbclass
> +++ b/meta/classes/deb-dl-dir.bbclass
> @@ -102,7 +102,7 @@ deb_dl_dir_export() {
> -maxdepth 1 -type f -iname '*\.deb' |\
> while read p; do
> # skip files from a previous export
> - [ -f "${pc}/${p##*/}" ] && continue
> + [ -e "${pc}/${p##*/}" ] && continue
> # can not reuse bitbake function here, this is basically
> # "repo_contains_package"
> package=$(find "${REPO_ISAR_DIR}"/"${DISTRO}" -name
> ${p##*/}) diff --git a/meta/classes/rootfs.bbclass
> b/meta/classes/rootfs.bbclass index 786682d9..f274443d 100644
> --- a/meta/classes/rootfs.bbclass
> +++ b/meta/classes/rootfs.bbclass
> @@ -308,7 +308,8 @@ rootfs_install_sstate_prepare() {
> # so we use some mount magic to prevent that
> mkdir -p ${WORKDIR}/mnt/rootfs
> sudo mount --bind ${WORKDIR}/rootfs ${WORKDIR}/mnt/rootfs -o ro
> - sudo tar -C ${WORKDIR}/mnt -cpSf rootfs.tar --one-file-system
> rootfs
> + lopts="--one-file-system --exclude-caches"
> + sudo tar -C ${WORKDIR}/mnt -cpSf rootfs.tar $lopts rootfs
> sudo umount ${WORKDIR}/mnt/rootfs
> sudo chown $(id -u):$(id -g) rootfs.tar
> }
> diff --git a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc
> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc index
> cb0079ec..44019f95 100644 ---
> a/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc +++
> b/meta/recipes-core/isar-bootstrap/isar-bootstrap.inc @@ -395,6
> +395,10 @@ EOSUDO
> # Cleanup apt cache
> sudo -Es chroot "${ROOTFSDIR}" /usr/bin/apt-get -y clean
> +
> + # Don't include apt cache into sstate cache by marking the
> directory
> + # with a CACHEDIR.TAG file with a special signature
> + sudo -Es sh -c "echo Signature: 8a477f597d28d172789f06886806bc55
What is that "special signature" all about? Does anyone later care to
remove the file again, or do we risk it ending up in the final rootfs?
I find this a little weird and would prefer if the calls to tar would
simply exclude this by path and not by magic tool specific file.
It could be made a central function so we have all those tar calls in
one place.
In this patch i see three places ... hard to maintain.
Henning
> > ${ROOTFSDIR}/var/cache/apt/archives/CACHEDIR.TAG" }
>
> addtask bootstrap before do_build after do_generate_keyrings
> @@ -405,7 +409,8 @@ SSTATEPOSTINSTFUNCS += "bootstrap_sstate_finalize"
>
> bootstrap_sstate_prepare() {
> # this runs in SSTATE_BUILDDIR, which will be deleted
> automatically
> - sudo tar -C $(dirname "${ROOTFSDIR}") -cpSf bootstrap.tar
> --one-file-system $(basename "${ROOTFSDIR}")
> + lopts="--one-file-system --exclude-caches"
> + sudo tar -C $(dirname "${ROOTFSDIR}") -cpSf bootstrap.tar $lopts
> $(basename "${ROOTFSDIR}") sudo chown $(id -u):$(id -g) bootstrap.tar
> }
>
next prev parent reply other threads:[~2023-01-06 15:58 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-06 6:48 [PATCH v2 0/3] Improving apt cache Uladzimir Bely
2023-01-06 6:48 ` [PATCH v2 1/3] Clean apt cache from debootstrapped rootfs dirs Uladzimir Bely
2023-01-06 6:48 ` [PATCH v2 2/3] Use hardlinks in deb-dl-dir functions Uladzimir Bely
2023-01-06 6:48 ` [PATCH v2 3/3] Changes for a faster build using less disk space Uladzimir Bely
2023-01-06 15:58 ` Henning Schild [this message]
2023-01-06 17:38 ` Uladzimir Bely
2023-01-06 17:52 ` Roberto A. Foglietta
2023-01-06 18:11 ` Henning Schild
2023-01-09 6:32 ` [PATCH v2 0/3] Improving apt cache Moessbauer, Felix
2023-01-09 7:39 ` Uladzimir Bely
2023-01-19 7:36 ` Uladzimir Bely
2023-01-19 14:52 ` Roberto A. Foglietta
2023-01-19 16:30 ` Roberto A. Foglietta
2023-01-20 4:44 ` Uladzimir Bely
2023-01-20 5:08 ` Moessbauer, Felix
2023-01-20 7:01 ` Uladzimir Bely
2023-01-20 7:12 ` Roberto A. Foglietta
2023-01-20 7:23 ` Uladzimir Bely
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=20230106165826.1346da94@md1za8fc.ad001.siemens.net \
--to=henning.schild@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