CCing #989905 (base-files) > Setting user-package-dir to a nonexistent directory also seems to > work. Nick, can you try the dh-elpa version at > https://salsa.debian.org/emacsen-team/dh-elpa ? Or just apply > > https://salsa.debian.org/emacsen-team/dh-elpa/-/commit/600a1133903eb2f7d3b7d954467dcee0b2d0277b > > to /usr/lib/dh-elpa/helper/install >
That's a cool low-friction solution! :-) P.S. How likely is a future where Emacs will return non-zero exit status if package-user-dir is not found? I'm guessing unlikely? > Some possible alternatives: > > 1) maybe Sean remembers the proposed convention for a known empty > directory? Is this usable in stable? > > 2) We could create and clean up an empty temporary directory > > 3) We could create /usr/lib/dh-elpa/empty I have no strong opinion towards any of these options, but I was shocked to discover that Debian didn't already have a /var/run/empty. So I filed #989905 requesting /var/run/empty (present in Fedora, RedHat, CentOS, SUSE, Arch, FreeBSD, and probably more). It's not FHS, but it seems like maybe it should be; although, a systemd-centric future probably dynamically creates empty paths as-needed... https://bugs.debian.org/989905 Maybe a TC member could say something about whether a canonical empty directory equivalent to /dev/null is good design? Unfortunately it won't help the situation in stable--unless base-files receives a stable-update. It seems like it might also require a point in Policy along the lines of "packages must not install files nor write to /var/run/empty". #1 (via #989905) seems the cleanest, most standard, and conventional to me, #2 seems like a maintscript (which are increasingly discouraged) or a dpkg feature, and it seems to me that #3 sets a precedent that sanctions the proliferation of empty directories (which is maybe harmless and only kind of ugly and confusing?). It's possible I'm biased, so I leave it to you! Cheers, Nicholas
signature.asc
Description: PGP signature
