<dwfreed>
stintel: since /var is default a symlink to /tmp and /tmp is default a tmpfs, it would probably be best to handle making the dir in initscript; if things need to persist across reboots, then yes they should be in /etc
<stintel>
dwfreed: there is no init script, but I suggested to do mkdir in the proto handler. and no. /etc is not the right place for a file that is changed by the daemon
rua has joined #openwrt-devel
<dwfreed>
stintel: I mean, if the file needs to persist across reboots without uci config to recreate it, then /var is the wrong place to put it
torv has quit [Remote host closed the connection]
torv has joined #openwrt-devel
<stintel>
I'm well aware of that, but I put it on /var/lib/thread for multiple reasons: it's the default, it won't end up on flash by default so no chance of killing flash and like this the user has to decide themselves if they want to do that, you can just use CONFIG_TARGET_ROOTFS_PERSIST_VAR=y
<dwfreed>
does it matter if the file doesn't persist
<stintel>
what do you mean?
<dwfreed>
meaning, in the default configuration, if the device reboots, is the whole setup still usable without manual intervention
<dwfreed>
with non-persistent /var
<stintel>
no
<dwfreed>
then it should not be in /var, full stop
<dwfreed>
because changing that config var requires a full source rebuild, basically (or you try to rebuild just base-files and replace it, but that gets hairy)
<stintel>
I'm not putting it in /etc, that is just wrong
<dwfreed>
that is the best place for it under the circumstances
<stintel>
a user can decide to do that, I will not be making that default in a package I maintain
<dwfreed>
then why ship a package that is broken by default?
Mangix has quit [Read error: Connection reset by peer]
<froztbyte>
hmm, before I start going down this rabbithole myself I figure it's best to maybe ask: if I wanted to cache parts of the build process in my CI setup, which bits are safe/which bits should I look at for cache invalidation? I've glanced at a couple of the buildfarm jobs to see how they run, but it's a bit of a pain to drill down into them and afaict there's no outwardly visible file that defines
<froztbyte>
the buildjobs and their setups there
<froztbyte>
right now I'm doing some jobs both targeting variations on 23.05.2 release, as well as some others tracking off snapshot at various commit refs. the 23.05.2 builds I figure I could cache the whole toolchain? but the others I figure there might be moving pieces