Hi Guillem, Quoting Guillem Jover (2019-03-15 05:22:32) > On Sat, 2018-11-24 at 10:24:09 +0100, Johannes 'josch' Schauer wrote: > > lintian recently tagged mmdebstrap with uses-dpkg-database-directly because > > mmdebstrap contains the string "/var/lib/dpkg" in several places. Instead > > of overwriting the lintian tag in mmdebstrap, dpkg could also gain an > > interface which avoids mmdebstrap having to do anything with /var/lib/dpkg > > inside the chroot. Specifically, what mmdebstrap does is the following: > > > > - create /var/lib/dpkg, /var/lib/dpkg/triggers, /var/lib/dpkg/info, > > /var/lib/dpkg/alternatives and /var/lib/dpkg/updates because dpkg > > throws an error if these directories are not present > Right, will handle those. > > > - an empty /var/lib/dpkg/status because dpkg refuses to work without > > the file being present > I've fixed this one now in a local next/bootstrap branch which I'll push out > tomorrow-
Cool! But I'll only follow up on this in mmdebstrap once we release Buster. :) Another file that I found is required is /var/lib/dpkg/available. If this file does not exist (it can even be empty) then package removals will fail. > > - adds architectures to /var/lib/dpkg/arch because $(dpkg > > --add-architecture) doesn't work without any packages inside the > > chroot > This sould already work when passing --root= or --admindir=, it should even > work w/o being root. :) How then are the foreign architectures communicated to dpkg if not via /var/lib/dpkg/arch? > > - cleans up leftover /var/lib/dpkg/lock-frontend and /var/lib/dpkg/lock > As mentioned on IRC, this should not be necessary, these are range-locks, and > they work not based on their presence, but whether they process has acquired > locks within them. Agreed. mmdebstrap already does not remove them anymore. Thanks! cheers, josch
signature.asc
Description: signature
