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. -- Roland Mas If you're ever confused as to which mode you're in, keep entering the <escape> key until vi beeps at you. -- nvi manual page. _______________________________________________ Fusionforge-general mailing list Fusionforge-general@lists.fusionforge.org http://lists.fusionforge.org/cgi-bin/mailman/listinfo/fusionforge-general
