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

Reply via email to