Hoi > ... but I'm still hesitant to carry this as an additional patch in > Debian: it really should be implemented upstream, since the FHS is not > Debian-specific at all.
I agree that it should be, and understand the hesitation but as long as it isn’t, Debian should make it behave sanely. > Plus, if implemented, what do we do with the data in the previous path? > Forcibly move it? Ignore it? Prompt the user? No change in behaviour, IMHO. If the package has not done anything with it, it shouldn’t start now. Especially because none of the options seem particularly good: * move it: no, that would be a mess and for what gain? * ignore it: if that’s what has been done until now, continue doing that. * prompt: no, this is IMHO not a good enough reason to force interaction. IMHO it’s also not good enough reason for notification, as in NEWS.Debian entry. People who care about the reports will (or at least should) already be taking care of them and notice when they are missing or in a new place. Or read it in the changelog. People who don’t care: well, they are already taken care off. Also: the reports have been in a directory that always has had the potential of being nuked for whatever reason. Other than mentioning it in the changelog, it should IMHO just be left with that. > Worth noting is that since the last puppet-agent upload, the reports > feature now defaults to disabled (no reports generated). Noted. Not sure how I feel about it, though … It’s probably better since there doesn’t seem to be any handling of old reports anyway, so this would (slowly) fill up diskspace if not handled specifically by the admin. Cheers henk On Sun, 17 Nov 2024 13:55:28 -0500 Jérôme Charaoui <[email protected]> wrote: > Hello, > > Le 2024-10-24 à 05 h 18, Hendrik Jaeger a écrit : > > According to upstream, the vardir is actually for caching stuff, so IMHO > > generally vardir being in /var/cache is not wrong. > > What I consider wrong, though, is putting reports there, as they cannot be > > regenerated which is what the FHS demands on data put there. > > And this should probably be forwarded upstream. > > (The same may be said about other things, like `bucketdir` and > > `clientbucketdir`, neither of which can be regenerated. But that should be > > a separate bug to not inflate this one!) > > > > To make a concrete suggestion: > > set reportdir = $logdir/reports > > > > What do you think? > > I think it would make sense, and your observations about the bucket > directories are also relevant. > > ... but I'm still hesitant to carry this as an additional patch in > Debian: it really should be implemented upstream, since the FHS is not > Debian-specific at all. > > Plus, if implemented, what do we do with the data in the previous path? > Forcibly move it? Ignore it? Prompt the user? > > Worth noting is that since the last puppet-agent upload, the reports > feature now defaults to disabled (no reports generated). > > -- Jérôme
