Re: [PATCH v2 0/3] Improving apt cache

[Uladzimir Bely <ubely@ilbers.de>]

In mail from пятница, 20 января 2023 г. 08:08:03 +03 user Moessbauer, Felix 
wrote:
> On Fri, 2023-01-20 at 07:44 +0300, Uladzimir Bely wrote:
> 
> > In mail from четверг, 19 января 2023 г. 17:52:37 +03 user Roberto A.
> > Foglietta 
> > wrote:
> > 
> > > On Thu, 19 Jan 2023 at 08:36, Uladzimir Bely <ubely@ilbers.de>
> > > wrote:
> > > 
> > > > I got time to get back to this patches and checked this moment.
> > > > And it
> > > > really
> > > > does not work as I expected.
> > > > 
> > > > Original patch includes the following:
> > > > 
> > > > -        --chroot-setup-commands="cp -n --no-preserve=owner
> > > > ${ext_deb_dir}/
> > > > *.deb -t ${deb_dir}/ || :" \
> > > > +        --chroot-setup-commands="ln -Pf ${ext_deb_dir}/*.deb -t
> > > > ${deb_dir}/
> > > > 2>/dev/null || :" \
> > > > 
> > > > This results to to failing "ReproTest" in CI with the following
> > > > error (for
> > > > libhello, for example):
> > > > 
> > > > sbuild-build-depends-dose3-dummy:armhf : Depends: dose-
> > > > distcheck:amd64 but
> > > > it
> > > > is not installable
> > > > E: Unable to correct problems, you have held broken packages.
> > > > 
> > > > To debug it, I removed `2>/dev/null` and found, that hardlinks
> > > > simply
> > > > don't
> > > > work and the following errors are now seen earlier:
> > > > 
> > > > ln: failed to create hard link
> > > > '/var/cache/apt/archives/adduser_3.118_all.deb'
> > > > => '/home/builder/libhello/rootfs/var/cache/apt/archives/
> > > > adduser_3.118_all.deb': Invalid cross-device link
> > > > ... #tons of similar errors...
> > > > ln: failed to create hard link '/var/cache/apt/archives/
> > > > zlib1g_1%3a1.2.11.dfsg-2+deb11u2_mipsel.deb' =>
> > > > '/home/builder/libhello/
> > > > rootfs/var/cache/apt/archives/zlib1g_1%3a1.2.11.dfsg-
> > > > 2+deb11u2_mipsel.deb'
> > > > 
> > > > :
> > > > 
> > > > 
> > > > Invalid cross-device link
> > > > 
> > > > I: Finished running 'ln -Pf
> > > > /home/builder/libhello/rootfs/var/cache/apt/
> > > > archives/*.deb -t /var/cache/apt/archives/ || :'.
> > > > 
> > > > So, it works for network builds (when missing packages always can
> > > > be
> > > > downloaded by apt), but it fails for local builds from apt-cache
> > > > (when, at
> > > > first network build, sbuild dependencies are simply not exported
> > > > to
> > > > download
> > > > directory due to non-working hardlinks, plus with hidden stderr)
> > > 
> > > 
> > > Hi, first of all I do not fully understand why we use ln -P instead
> > > of ln
> > > -Pf in the exporting debs.
> > > 
> > >         --finished-build-commands="ln -P ${deb_dir}/*.deb -t
> > > ${ext_deb_dir}/ 2>/dev/null || :" \
> > > 
> > > This code's goal is to build a deb that should be exported
> > > otherwise we are
> > > continuing using the old package. It seems that breaks things but -
> > > again -
> > > I did fully not understand what and why but simply accepted the
> > > suggestion.
> > > Now, I have reverted back to ln -Pf.
> > > 
> > > Second, those lines are supposed to fail - and obviously fail in
> > > both
> > > directions: import and export - but the following
> > > 
> > > (a) if export fail we will not have the custom packages but we have
> > > them
> > > (b) removing that lines and the code will always fail
> > > 
> > > These mean that ln -Pf complains to fail but make a difference and
> > > make the
> > > difference that we want. However, I might not have understood the
> > > case in
> > > which it fails completely so:
> > > 
> > > mv build/downloads .
> > > rm -rf build
> > > ./build.sh basic-os (DONE)
> > > ./clean.sh isar
> > > ./build.sh (DONE)
> > > ./clean.sh all
> > > ./build.sh (DONE)
> > > 
> > > remove that two lines about ln -Pf that are supposed to do nothing
> > > than fail
> > > 
> > > ./clean.sh all
> > > ./build.sh (DONE with the same building time)
> > > 
> > > rm -rf build/downloads
> > > mv downloads build
> > > 
> > > ./clean.sh isar
> > > ./build.sh complete (FAIL)
> > > 
> > > put back those two command lines with ln -Pf and
> > > 
> > > ./clean.sh all
> > > ./build.sh (DONE)
> > > 
> > > I do not say you are wrong and I see ln -Pf complains on stderr but
> > > nothing
> > > that tin my private fork cannot be solved using a stderr
> > > redirection to
> > > /dev/null
> > > 
> > > However there are some other ways to do this thing:
> > > 
> > > 1. sbuild uses schroot by default, using chroot instead
> > > 2. keep the default in schroot, elsewhere it uses upper folder that
> > > can be
> > > populated in advance
> > > 
> > > I did not make any changes because I did not identified the issue.
> > > 
> > > Best regards, R-
> > 
> > 
> > I'll try to make things clear. Isar supports local builds from 'base-
> > apt' repo 
> > with.
> > 
> > First build user does as usual.
> > 
> > Second build is done with the following changes (at least):
> > 
> > ISAR_USE_CACHED_BASE_REPO = "1"
> > BB_NO_NETWORK = "1"
> > 
> > In this case every .deb we downloaded from Debian mirrors at first
> > build goes 
> > to local 'base-apt' and second build use it, but not remote mirrors.
> > 
> > That's the reason of using this "cp/ln magic" inside of sbuild. While
> > building 
> > some package, multipe dependencies might be downloaded inside of
> > sbuild. And 
> > we need a way to extract them from "internal" apt-cache in sbuild
> > schroot and 
> > put to the package workdir, where deb-dl-dir export will pass them to
> > DL_DIR 
> > later.
> > 
> > When we replace copying to hardlinks, that actually don't work due to
> > different filesystems, we come to the situation, when multiple debian
> > packages 
> > (dependencies of what we are building or some packages that sbuild
> > requires 
> > itself) are not present in DL_DIR. So, second "cached" build from
> > local repo 
> > simply fails.
> > 
> > I see the following possible solutions that allows to save space.
> > 1. Since hardlinks don't work, try to use symlinks.
> 
> 
> If that works, it clearly is the simplest solution.
> 

Yes, approach with symlinks inside sbuild chroot seems to be working, so I'm 
going to use it in patchset v3.

> 
> > 2. Don't use import with sbuild at all, but only export. But this has
> > a 
> > drawback, when all packages we build with sbuild might download the
> > similar 
> > dependencies in parallel.
> 
> 
> A third solution might be to mount the cache into the schroot, similar
> to how we handle the sstate cache today.
> 
> Anyways, I would appreciate if we could merge this series even if it
> still does not fully solve the quadratic behavior. It is very valuable
> and "good enough" even for my biggest layers.
> 
> Felix
> 
> 
> > 
> > 
> 
>