Re: [BackupPC-devel] 3.0beta - Convert old files layout to FHS

[Craig B. <cba...@us...>]

Vincent writes:

> I've upgraded my existing setup to 3.0beta0: all is up and runnig.  :-)=

>=20
> Now I would like to convert my (existing) file layout to the new FHS
> compliant layout introduced with 3.0beta0.
>=20
> As far as I know, I need:
>=20
> 1 - to create both /etc/BackupPC and /var/log/BackupPC directories
> (and of course  to move existing configuration and log files)
>=20
> 2 - to edit config.pl and change both $Conf{ConfDir} and $Conf{LogDir}
>  accordingly;

Yes.

> Questions:
>=20
> Will I have to re-run the configure.pl installation script so that
> theses changes are taken into account?  In particular: how will the
> the BackupPC init script be aware of the new path  of the config.pl
> main configuration file?

You need to re-install BackupPC after making the above
changes since the config path and FHS settings are merged
into lib/BackupPC/Lib.pm when the upgrade/installation is
done.

> Another thing: to be more consistent, wouldn't it be better to name
> the directories /etc/backuppc and /var/log/backuppc instead of
> /etc/BackupPC and /var/log/BackupPC? We allready have
> /usr/share/backuppc/ (at least on my Mandriva system)...

I thought about that but I decided to stick to BackupPC.
I think the Debian package uses /etc/backuppc, so there is
some minor inconsistency.  The package maintainers can decide
whether to keep /etc/backuppc or not.  You can use arguments
to configure.pl to use whatever path you please.  Do
"perldoc configure.pl" to see all the arguments.

This does raise a question: I decided to keep BackupPC 3.x fully
backward compatible with the file layout when upgrading an existing
installation, so it doesn't impose FHS on an upgrade.  Although it
requires some effort and testing, configure.pl could instead force
FHS on upgrade and automatically move the config files to their
new locations.

I'm going to keep it the way it is (FHS only on new installations)
unless people have strong opinions otherwise.

Craig