Julien ÉLIE <jul...@trigofacile.com> writes: > An interesting directory would be <pathdb>. Why not use <pathdb> > for that pullnews state file? > We have active.times and newsgroups there for instance.
> Instead of using ".pullnews", why not use "pullnews.marks" (or any better > name without an initial dot? "marks" was for high/low water marks) Ah, yes, that's exactly the directory that I was mentally reaching for. Thank you! And yes, renaming the file sounds like a good idea to me. > By the way, should files like control.log and unwanted.log also be > in <pathdb> (under maybe another name) or are there fine in <pathlog>? > And expire.lastlowmark, expire.list, expire.log? > Of course we *log* message-IDs in expire.list or newsgroups in > unwanted.log but we also *log* creation times in active.times :) active.times is a persistent record of creation times that's part of the protocol and returned to the client, though. Those others really are log files, although log files that store only cumulative statistics in some cases. You can delete them completely with no consequences other than losing history; there are no protocol implications. I think that makes them different. expire.lastlowmark and expire.list are really temporary files more than log files, but since they're handy to keep around for a day in case something goes wrong, I think treating them as transient log files is okay. > Another file that should be created is the state of the last processed > checkgroups (for checking the serial number, according to RFC 5537). > Will <pathdb> be the right place for it? Yes. > <pathdb> is /var/lib/news/ in Debian, with 775 news/news so it would > be fine for the news user. > However, according to FHS, users must never need to modify files in > /var/lib to configure a package. Yet, ".pullnews" needs to be > initialized. Or we should change how pullnews works, with a > configuration file in <pathetc> and its state in <pathdb>... I vote for the latter. Separating state and configuration is almost always a good idea. > Incidentally, as for <pathspool>, shouldn't some files like > tradspool.map or group.index be better in <pathdb>? The distinction > between /var/lib and /var/spool according to FHS is not clear about > where they should belong to... group.index is part of the overview data structure, so I think it should stay with the rest of the overview data. You want to delete it if you're deleting all the overview data, and it's meaningless if you switch overview methods. Similarly, tradspool.map is part of the (otherwise very simple) data structure used to store traditional spool, playing a role like the header of a CNFS buffer, and is necessary to be able to retrieve any articles from the spool via the storage API. So I'd keep it with the rest of the spool. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org