So there are 3 distinct interlinked goals:

- tmpfiles.d itself
  - recovering from missing /var (+ later /etc)
  - volatile file tracking

Just finishing the first step without going to far in either
other tracks would be so great already.


Le dim. 17 sept. 2023 à 19:57, Russ Allbery <r...@debian.org> a écrit :
> Luca Boccassi <bl...@debian.org> writes:
> > We are working on that. This means that tmpfiles.d would be able to both
> > create the files/dirs when needed, and remove them when unneeded, ie on
> > purge - as far as I can tell, that would be the only useful thing that a
> > dpkg integration would provide.
>
> dpkg -S is the most useful feature this supports for me personally (and
> some related things, such as cruft-finding).

I agree.

And when "dpkg -S file" fail,
just try "cruft /path/file".

It is slow, the implementation *is* bad - more like a unit test -
but should know about most files, and it still faster
than starting googling for the filename and getting distracted:

$ LANG=C dpkg -S  /var/log/dpkg.log
dpkg-query: no path found matching pattern /var/log/dpkg.log
$ time cruft /var/log/dpkg.log
dpkg
real    0m7,129s

The ugly magic behind the curtain:

ls /usr/libexec/cruft/ -1
  LOGROTATE -> that parses these for path
  SERVICES -> added today reading this discussion, it reads
                         CacheDirectory= & StateDirectory= from *.service
  TMPFILES  -> that parses these for path


This whole thing, while being already usefull & used,
is more like a mockup of what could be a "perfect" dpkg.

These tiny shell scripts could be converted into something else
that plugs into dpkg ... for example tiny .so plugins that answer
which package own which dynamic file ?

(for runtime evaluation, other possibility is debhelper magic at compile-time
that generate a list of possible files)

> More generally, dropping directories that are currently registered with
> dpkg from dpkg's database is a regression.

I agree.


I've mounted /var/cache/apt/archives everywhere on a tmpfs since forever,
apt will now how/when to recreate /partial subdir,
but yet it's nice to have it in dpkg register.

> Specifics!  Specifics!  My kingdom for specifics!  :)

There's indeed not so much remaining in the way for /var,
some files could be replaced by tmpfiles.d generated symlinks

$ cat /var/lib/dpkg/info/*.list | grep ^/var | sort -u | while read f;
do test -f $f && echo $f; done | wc -l
256

$ dpkg -S $(cat /var/lib/dpkg/info/*.list | grep ^/var | sort -u |
while read f; do test -f $f && echo $f; done) | cut -d: -f1 | sort -u
aspell-en
dictionaries-common
ifrench: /var/lib/dictionaries-common/ispell/ifrench -> generated metadata
plocate:       CACHEDIR.TAG
poppler-data:    only transitional symlinks to /usr/share/poppler ?
ttf-mscorefonts-installer:     only one file that could be symlinked from /usr
xserver-common:           /var/lib/xkb/README.compiled, could be a
symlink from /usr/share/doc

Maybe /etc in a later track.

Greetings,

(I find this thread greatly inspirational)

Reply via email to