tags 308001 moreinfo quit * Marc Haber
> torrus is an example of the other kind. I remember not liking the > cricket packaging at all, and mrtg is probably not a very good > example. I'm not so sure if I like the torrus packaging, with one binary package per httpd. 19 packages is providing "httpd" as far as I can see, and I'd like Munin to work with all of them, but having one binary package per httpd doesn't seem like a viable option. Shipping example configuration for them in the main Munin package is possible, but would be a maintenance nightmare. Or I could do like the torrus maintainer seems to do and only support the Apache servers, but that would be a bit sad too. Using /var/www/munin is quite nice in that case, as it'll work with any web server without any extra configuration needed. * Tore Anderson > ÂWeb Application shold try to avoid storing files in the Web Document > Root [, but rather create it's own subdir in it]Â. * Marc Haber > I do not concur with that interpretation, since the policy quite > clearly states that packages should use /usr/share/doc/package (which > is wrong, btw, since nothing should rely on /usr/share/doc being > present). Well, I won't claim I'm certain I'm right. Didn't think very much about it back then, now I'm not so sure any longer thanks to you. :-) But I'm not convinced that I was wrong either.. > I think it is fine to ship static files in /var/www, but dynamically > generated stuff which is painless to lose (like the .png files) > should, IMO, be in /var/cache, and dynamic data which has value (like > the .rrd files) should be in /var/lib. In my opinion, the value of the > data should take precedence to its use when judging where to store it. > /var/cache could be a ram disk and not being backupped, and I could > surely come up with a situation where /var/www and /var/lib could be > treated differently storage-, backup- and purge-wise. Well, it's /var in any case, which the FHS says is for "variable data files", so it's unsuitable for fully static files which will never change (ie. files contained in the data.tar.gz part of the .deb), IMO. /usr/share strikes me as the proper place for this. /var/cache does not seem to me like an unreasonable place for the Munin output, based on the FHS description, though. But /var/www seems to be a "Debianism" that's not mentioned in the FHS, so its intended usage isn't quite clear to me. As noted above, I disagree that fully static data should be under /var at all. Data that's constantly or periodically changing should. But, I wonder, is there some middle ground here? Should /any/ package be allowed to put files in /var/www, or should it go into /var/lib or /var/cache, depending on the data can be regenerated easily or not? Is there a middle ground here, some kind of package that doesn't fit into either /usr/share, /var/cache, or /var/lib? I cannot think of one, yet there are 60 packages that put stuff in /var/www (possibly more, if they do it exclusively run-time and put nothing into data.tar.gz). Is a mass bug filing warranted, or is Munin special in some way that makes it not OK to use /var/www while all the others should? The Policy editors have said repeatedly that Policy is supposed to document current practise. It obviously doesn't here (or at least isn't clear enough), which is in my opinon a good reason to make this issue more visible, on the debian-devel mailing list. I've decided to bring it up there and see if there's some kind of consensus after Sarge's released. Tagging the bug moreinfo while I await the outcome of this discussion. This bug (if it indeed is) won't be fixed before Etch anyway, so there's no need to rush any change. As you point out with the mention of /usr/share/doc, the relevant Policy passage needs improvement anyway. > I have discussed this on #d-d. Formally, the idea is that web > application register with the menu package and the web swerver queries > menu for the packages being installed and configures itself > apropriately. That mechanism seems not to be in wide use though. Cheers to documenting current practise... :-P I cannot even find support for this in any of the utilities provided in the menu package. So it seems this is also an issue that should be fixed in the Policy. Regards, -- Tore Anderson
