[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

FSVS and versioning /etc



Hello everybody!

Now that FSVS has made it into debian (http://packages.debian.org/fsvs) I'd 
like to make it easier for users to keep track of their systems' 
configuration.

I asked Sheldon to build a package fsvs-system-versioning; that will depend on 
fsvs, and provide some default configuration to keep /etc versioned.


Some facts:
* A lot of filename patterns are just ignored, like *.dpkg-old.
* Some files have a commit-pipe defined, so that eg. the passwords get
  stripped out of the shadow files.
  In case of a restore all passwords have to be set afresh.
* For a few files that include passwords (like ddclient) there are
  already filters.
* Currently I use the apt option Dpkg::Post-Invoke to commit, although
  some anacron-job once a day or week might be good.
  Another idea might be to commit a new version only once per apt-get run.
* This is thought to help *configuring* the system; that means that both
  system updates (and installations) and user changes should be versioned.
* Needed space for the repository is on my system (with 1853 installed 
  packages) about 12MB for the initial import; the few changes up to now
  take no space (10 to 30kB).


Now there are some open questions.

1) Does apt export some state about the current installation 
   (eg. via the environment)?
2) Should we call fsvs after each *single* package? Together with 1 that
   would allow to see exactly which installation caused some change.
3) Apart from the few files I saw that should be kept secret 
   (and so either have to be modified for commit, or ignored fully),
   there'll be some more.
   Should all be kept in fsvs-system-versioning, or should each package
   (later, when they're converted) have some header in its control part?
   Another way would be to provide some functions in 
   /etc/system-versioning.sh, like "commit", "ignore", and 
   so on ... but eg. the commit-pipe is more or less fsvs-specific, and 
   we'd have to ship some empty functions per default (in case fsvs is 
   not installed).
   Another idea would be some /etc/fsvs-versioning/ignore.d/ directory,
   where packages could drop their lists of files to be ignored, and some
   update-fsvs-versioning.
4) fsvs can do empty commits, to record the fact that nothing changed.
   Should we avoid that? Currently the "Urls" file gets committed, because
   the local revision is changed after every commit. Should that file
   be ignored, to avoid needless use of disk-space?


Currently the ignore patterns are relative to the working copy root; this is 
no problem for /etc itself, but if someone wants to use the same mechanism to 
keep / versioned all the ignore patterns have to be re-done, to include 
the /etc part. But that's something that I'll change in fsvs - some way to 
define absolute ignore patterns.


Thank you for your comments!
  Please keep us CC'ed. Thank you.


Regards,

Phil

-- 
Versioning your /etc, /home or even your whole installation?
             Try fsvs (fsvs.tigris.org)!


Reply to: