Re: master 2772ebe366: Do not prune native-compiled system directories (bug#59658)

[Juanma Barranquero <lekktu@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1499 bytes --]

Yes, I see. We'll have to decide where's the error, or what's the intended
behavior.

test-native-compile-prune-cache sets native-comp-eln-load-path to a single
directory and then tests whether native-compile-prune-cache can delete a
stale cache dir inside it (and keep a non-stale one).

It is obviously going to fail with my fix, because with it installed,
native-compile-prune-cache is never going to delete anything in the last
(or, in this case, unique) directory in native-comp-eln-load-path, because,
as the docstring of native-comp-eln-load-path says, "[t]he last directory
of this list is assumed to be the system one" (i.e, the one containing the
preloaded/ subdirectory and its content).

So, alternatives:

1.- We fix the test so it sets native-comp-eln-load-path to a list of two
directories, and checks that the stale subdir is deleted in the first, and
nothing is deleted in the second ("system") one.

2.- We remove my change and allow that native-compile-prune-cache sometimes
deletes files in the "system" eln cache, but Eli argued that we don't know
if the user will have write access to it, and we're not sure we *want* to
allow native-compile-prune-cache to delete files there...

3.- Or we find a way to reliably decide whether a cache directory is, in
fact, the "system" one (which we can currently do, heuristically, because
it contains preloaded/), and fix *both* my patch and the test so it only
considers untouchable those cache directories that really are "system" ones.

[-- Attachment #2: Type: text/html, Size: 1915 bytes --]