Re: Better way to handle apt cache needed

["Moessbauer, Felix" <felix.moessbauer@siemens.com>]

On Fri, 2022-12-30 at 00:15 +0100, Roberto A. Foglietta wrote:
> Hi all,
> 
> I did some changes to reduce disk usage and to speed up the building.
> The results are quite impressing so, before everything else I am
> going
> to show you the numbers:
> 
> results before and after the changes
> 
> 43954 Mb (max)   |  8657 Mb (max)
> 26548 Mb (rest)  |  4118 Mb (rest)
>  3741 Mb (deb)   |  3741 Mb (deb)
>   820 Mb (wic)   |   820 Mb (wic)
> 11789 Mb (cache) |   579 Mb (cache)
> time: 8m33s      | time: 4m34s
> 
> The changes has been committed on the default branch (evo) on my ISAR
> fork
> 
>  https://github.com/robang74/isar
> 
> * 9fd5282 - changes for a faster build using less disk space, p.1

Hi Roberto,

I tested your patches. In general, the implemented pattern looks good
and also result in significantly shorter build times on virtual file
systems.

But I discovered some issues on partial rebuilds. Example:
| ln: will not overwrite just-created '/build/tmp/deploy/buildchroot-
target/debian-bullseye-amd64/var/cache/apt/archives/libnet-ssleay-
perl_1.88-3+b1_arm64.deb' with '/build/downloads/deb/debian-
bullseye/libnet-ssleay-perl_1.88-3+b1_arm64.deb'

This happens in the do_install_npm in the npm class of meta-iot2050
[1].
It could also be an issue with an older sstate cache artifact, or
related to the specific implementation in the NPM class.
Needs further investigation.

[1]
https://github.com/siemens/meta-iot2050/blob/master/classes/npm.bbclass#L105

Best regards,
Felix

> * 1b6ac1e - bugfix: no sstate archive obtainable, will run full task
> instead
> * 2cc1854 - bugfix: do_copy_boot_files was able to fail but then set
> -e
> 
> The two bug fixes are necessary to test for regression because the
> top
> commit changes the sstate cache creation. The top commit uses hard
> physical links to obtain these results, so it may not work in some
> cases like distributed or networked filesystems which do not support
> hard links (however, they might be smart enough to do a bare copy but
> I cannot grant that).
> 
> However, this is the reason because I titled part one the patch. I am
> thinking of addressing the issue in a more radical way but for the
> moment this seems quite interesting.
> I wish to have some feedback about the limitation about using
> uncommon
> filesystems and which one have a nice fallback to address unsupported
> features.
> 
> Looking forward your opinions, R-