public inbox for isar-users@googlegroups.com
 help / color / mirror / Atom feed
From: Henning Schild <henning.schild@siemens.com>
To: <Venkata.Pyla@toshiba-tsip.com>
Cc: <jan.kiszka@siemens.com>, <isar-users@googlegroups.com>
Subject: Re: [PATCH v2] rootfs: clean package log files that are not owned by packages
Date: Mon, 4 Oct 2021 14:36:50 +0200	[thread overview]
Message-ID: <20211004143650.13c04f29@md1za8fc.ad001.siemens.net> (raw)
In-Reply-To: <OSYPR01MB5542A7466586445340B5C12DA4AE9@OSYPR01MB5542.jpnprd01.prod.outlook.com>

Am Mon, 4 Oct 2021 10:47:10 +0000
schrieb <Venkata.Pyla@toshiba-tsip.com>:

> Hi Jan,
> 
> Thanks for the review, please find my inline comments.
> 
> >-----Original Message-----
> >From: Jan Kiszka <jan.kiszka@siemens.com>
> >Sent: 04 October 2021 15:26
> >To: pyla venkata(TSIP) <Venkata.Pyla@toshiba-tsip.com>; isar-
> >users@googlegroups.com
> >Cc: henning.schild@siemens.com
> >Subject: Re: [PATCH v2] rootfs: clean package log files that are not
> >owned by packages
> >
> >On 01.10.21 16:37, venkata.pyla@toshiba-tsip.com wrote:  
> >> From: venkata pyla <venkata.pyla@toshiba-tsip.com>
> >>
> >>  /var/log/* files that are created during build stage and not owned
> >> by any package are not neccessary to be present in rootfs image, as
> >> these log files adds additional size to rootfs image, and also it
> >> create problems for reproducible build functionality.
> >>
> >>  so this ROOTFS feature 'clean-log-files' should help to clean the
> >> log files when it is enalbed, disable it if we need the log files
> >> for debugging purpose.
> >>
> >>  ROOTFS_FEATURE += clean-log-files
> >>  
> >
> >Style: Do not indent the commit body. I think this will survive "git
> >am" and will make the result look inconsistent.  
> 
> Thanks for correcting me, I will send the patch again with corrected
> comments.  
> 
> >  
> >> Signed-off-by: venkata pyla <venkata.pyla@toshiba-tsip.com>
> >> ---
> >>  meta/classes/rootfs.bbclass | 10 ++++++++++
> >>  1 file changed, 10 insertions(+)
> >>
> >> diff --git a/meta/classes/rootfs.bbclass
> >> b/meta/classes/rootfs.bbclass index f9151c5..ff0ecad 100644
> >> --- a/meta/classes/rootfs.bbclass
> >> +++ b/meta/classes/rootfs.bbclass
> >> @@ -12,6 +12,7 @@ ROOTFS_PACKAGES ?= ""
> >>  # 'clean-package-cache' - delete package cache from rootfs  #
> >> 'generate-manifest' - generate a package manifest of the rootfs
> >> into ${ROOTFS_MANIFEST_DEPLOY_DIR}  # 'export-dpkg-status' -
> >> exports /var/lib/dpkg/status file to
> >> ${ROOTFS_DPKGSTATUS_DEPLOY_DIR} +# 'clean-log-files' - delete log
> >> files that are not owned by packages ROOTFS_FEATURES ?= ""
> >>
> >>  ROOTFS_APT_ARGS="install --yes -o Debug::pkgProblemResolver=yes"
> >> @@ -213,6 +214,15 @@ rootfs_postprocess_clean_package_cache() {
> >>      sudo rm -rf "${ROOTFSDIR}/var/lib/apt/lists/"*
> >>  }
> >>
> >> +ROOTFS_POSTPROCESS_COMMAND +=  
> >"${@bb.utils.contains('ROOTFS_FEATURES', 'clean-log-files',
> >'rootfs_postprocess_clean_log_files', '', d)}"  
> >> +rootfs_postprocess_clean_log_files() {
> >> +    # Delete log files that are not owned by packages
> >> +    sudo -E chroot '${ROOTFSDIR}' \
> >> +        /usr/bin/find /var/log/ \
> >> +        -exec sh -c '! dpkg -S {} > /dev/null 2>&1' ';' \
> >> +        -exec rm -rf {} ';'
> >> +}
> >> +
> >>  ROOTFS_POSTPROCESS_COMMAND +=  
> >"${@bb.utils.contains('ROOTFS_FEATURES', 'generate-manifest',
> >'rootfs_generate_manifest', '', d)}"  
> >>  rootfs_generate_manifest () {
> >>      mkdir -p ${ROOTFS_MANIFEST_DEPLOY_DIR}
> >>  
> >
> >Is there any reason why this feature should be default-off? If not,
> >I would also add it to image.bbclass, ROOTFS_FEATURES.  
> 
> No reasons to set it to off, I taught to enable this feature where it
> is required (isar-cip-core), But, It is good idea to enable in
> upstream also.
> 
> If no objection I can send the patch with enabling this feature in
> image.bbclass

Seems to boil down to what i suggested ... even not making it optional
at all as long as we do not know of any reason to not clean up.
Saving space is someone we can assume anyone will want. Reproducability
is just a nice side effect ;)

Henning

> >
> >Jan
> >
> >--
> >Siemens AG, T RDA IOT
> >Corporate Competence Center Embedded Linux  


  reply	other threads:[~2021-10-04 12:36 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-06  9:45 [isar] rootfs: Add new ROOTFS_FEATURE 'slimfy' to minimize the footprint venkata.pyla
2021-09-06 10:13 ` Jan Kiszka
2021-09-06 10:48 ` Henning Schild
2021-10-01 14:37   ` [PATCH v2] rootfs: clean package log files that are not owned by packages venkata.pyla
2021-10-04  9:55     ` Jan Kiszka
2021-10-04 10:47       ` Venkata.Pyla
2021-10-04 12:36         ` Henning Schild [this message]
2021-10-04 12:05     ` Henning Schild
2021-10-04 12:51       ` Venkata.Pyla
2021-10-04 13:48         ` Henning Schild
2021-10-04 15:07           ` Venkata.Pyla
2021-10-04 16:45             ` Henning Schild

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=20211004143650.13c04f29@md1za8fc.ad001.siemens.net \
    --to=henning.schild@siemens.com \
    --cc=Venkata.Pyla@toshiba-tsip.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