Hi,
A status update on this:
0. Update the defaults in the *.ini files. Simple, easy, and I have it
done in a working copy here.
Still not committed, but I still have the patch here.
1. Ship the files in their appropriate location. That's easy too: I
updated debian/rules, fusionforge.spec, and the install/* scripts to
reuse the paths defined in the *.ini files.
Done.
2. Make sure the files (libraries, snippets, config files, data files)
are looked up in the right place.
Done.
2c. For (the few) Perl scripts: since we don't ship proper Perl modules
but only a couple of include files, we can't really pass the Perl
interpreter a path where it would look up our "include.pl". So I
replaced the hardcoded paths with @SOURCE_PATH@ macros and similar, and
updated debian/rules to sed in the actual path at package build time.
I'll do the same for the spec file and the install/* scripts.
Actually, I realized later that there's no need for such a macro, we
can just call `forge_get_config source_path` at runtime. Ditto for the
(few) Python files (in the moinmoin plugin).
2d. The data directory is very rarely referred to with an absolute
path, it's mostly through the config system. I'll make sure that "very
rarely" converges to "never", or use a similar macro system.
Still TODO.
3. (Hardest part) Migration on upgrade. What do we do on package
upgrade?
Not done.
3a. Migrating config files: should be reasaonably simple. dpkg has
helpers to move existing config files to a new location, and I guess we
can code similar things for the .spec file. I'm not sure about the
scripted installation; does it support upgrades? Do I need to care?
TODO.
3b. Migrating code: should be taken care of by the packaging system, so
probably nothing to do there.
Must check.
3c. Migrating the data dir: I'd be tempted to reuse the existing data
dir on upgrade, because setting up a new directory will likely lead to
massive breakage: in many cases, the /var/lib/*forge dir is specific in
some way (separate disk partition, NFS mount, or something). New
installations can use /var/lib/fusionforge, but for upgrades I think
it's safer to keep gforge and document the manual steps required to
complete the transition.
TODO: write a documentation.
So far, I haven't handled migration at all, just installation from
scratch (but the testsuite passes :-). I'm working on a branch based on
the Debian packaging, but of course I'll push the adequate changes
upstream as soon as I'm sure it works reliably.
The parts about replacing the hardcoded paths with lookups have been
pushed in both 5.3 and master (+ the relevant Debian branches), and the
testsuites pass on buildbot.ff.org. The part actually changing the
paths passes my testsuite locally, but I haven't pushed it yet. I'll
push it to master only, but first I'll write the migration system for
upgrades.
One particular concern is the macro system: it needs preprocessing at
package build time or at install time.
No longer needed :-)
Roland.
