Re: VINYL_STATE_DIR revisited (…and its creation)

[Nils Goroll]

Hi Oliver,

thank you for getting in touch. I want to say upfront that I am really not 
knowledgeable in software packaging and appreciate any help and advice.

 > First of all, changing such important data location defaults in a minor 
security patch release is not great from a packager's point of view. But that 
happened, let's move on.

Sorry. See above.

> I'd like to understand your reasoning behind that Makefile decision and work on a solution that allows building in the Nix sandbox with a custom statedir and avoids patching the makefile.

The relevant discussion is in 
https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/4477 and linked tickets.

The fundamental problem here is that, from a performance perspective, we 
_really_ want the state directory to reside on a tmpfs, but it can not be noexec 
(iow, we need to run code (= the compiled VCL) from it), see 
https://vinyl-cache.org/docs/trunk/installation/platformnotes.html#on-linux-use-tmpfs-for-the-workdir

I had made an attempt to find a default which would work for most, but then had 
to learn: 
https://code.vinyl-cache.org/vinyl-cache/vinyl-cache/issues/4477#issuecomment-60406

Nils

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x1DCD8F57A3868BD7.asc
Type: application/pgp-keys
Size: 4845 bytes
Desc: OpenPGP public key
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260821/6e381912/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://vinyl-cache.org/lists/pipermail/vinyl-dev/attachments/20260821/6e381912/attachment-0001.bin>