[PATCH] 2/2: Associate file locations to newly introduced path variables

[Christian Perrier]

Quoting Gerald (Jerry) Carter (jerry at samba.org):

> > Your comment certainly applies to the third patch of 
> > this series, the one I *didn't* forward, which is the one
> > that changes the location for state and cache paths from
> > /var/lib/samba to /var/cache/samba and /var/run/samba
> 
> What I've yet to be convinced of is that there is any benefit
> to Samba users with this patch.  if you can convince me that
> this improves Samba, I'll concede.

If you actually apply both patches, let's be honest: there will be
indeed *no change* for Samba users, when they use the upstream source.

Again, these two patches are not meant to modify Samba's behaviour wrt
files locations: they are meant to *alow* this to happen, if users
want to.

So, the benefit lies in this: it gives Samba users more
configurability for the file locations, whatever their religious
beliefs are about where files should lie...:-)

If we define ourselves (Debian *and* Ubuntu maintainers) as "users",
this gives us the great benefit of a much much easier build of new
versions, by reducing the size of our diff file by about one order of
magnitude.

If we define *other* distros as users, they would benefit of this
too...if we assume that all of them should indeed try to implement the
FHS as precisely as possible.

> 
> My objection to /var/cache is that in the past we've had
> problems with distro bugs that removed these files at reboot.

Well, from what both Steve and I quoted, those distros are buggy if
they remove the contents of /var/cache. The FHS makes it clear that it
should not be emptied between reboots (while /var/run can).

> 
> 
> > /var/cache is intended for cached data from applications.
> > Such data is locally generated as a result of time-consuming
> > I/O or calculation. The application must be able to
> > regenerate or restore the data.
> 
> And as I've already said, $(lockdir)/printing/*tdb doesnn't
> match this in any case.  In fact, non of the data can actually
> be regenerated since it represents state and historical data.

Well, we can try another approach if you agree: let's take all files
that our patch is reassigning and try to see if we agree about what
FHS definition they fall under.

Then, at least for those we agree about (as Steve pointed, that could
be 75% of the patch), I can re-propose a fhs-filespaths-OK.patch.

> 
> > As one sees, the "clear if first" files fall in that
> > category.....but not only these ones.
> 
> Yes they are.  Steve has convinced me that these could go
> in /var/run/samba/ but I still don't see any benefit to Samba.

One benefit could be that you (maintainer of .deb packages for Debian
and Ubuntu) and us could more easily converge towards a common set of
patches and build process.

Benefit: save Jerry's time..:-)

Another benefit is what I mentioned above about all distros and
vendors (not only Linux) to fit their respective policy wrt files
locations.