Package: rtfm Version: 2.0.3-1.1 Severity: important As described in #429074, we want to remove request-tracker3.4 before lenny in favour of request-tracker3.6. Before that can be done rtfm must be updated to work with request-tracker3.6. Since rtfm is currently orphaned (#419078), I intend to adopt it for the Debian Request Tracker Group to get this done. I'm filing this mostly to document the current situation, but if request-tracker3.4 is removed before fixing this it's going to become 'serious'.
The current rtfm version in Debian, 2.0.3, is quite old. I have packaged the slightly newer 2.0.4 release in the pkg-request-tracker alioth SVN repository [1], but my testing indicates that it doesn't work properly with request-tracker3.6 (tested with 3.6.4-1). There are problems in updating articles that I don't really want to dig into, given that upstream recommends 2.2.0 release candidates over the 2.0 series. The 2.2.0 release is scheduled for this fall [2], so there should be plenty of time to get it into lenny. [1] http://svn.debian.org/wsvn/pkg-request-tracker/ [2] http://bestpractical.com/rtfm/ Now, the 2.2 series needs some database modifications that must be run on upgrades from 2.0.x. This means that we need to handle both the move from RT 3.4 to 3.6 and the RTFM 2.2 database upgrade on the same go. Even though the current rtfm package doesn't do any database manipulation in its maintainer scripts, I don't think it is acceptable to continue doing so. (An almost acceptable solution would be to have a new rtfm-2.2 package that only works with request-tracker3.6, and tell the users to do the upgrade manually. I suppose this is the backup plan.) My preliminary plan for the upgrade is as follows: - the new rtfm will only Depend on request-tracker3.6. However, it it detects (how?) that request-tracker3.4 is also installed and has a working configuration, it will ask the user (via debconf, of course) which RT version should be used. It should also mention that 3.4 is no longer really supported. + this needs to be done so that there's an upgrade path for etch users with rtfm on request-tracker3.4; they can't upgrade their installation to 3.6 inside Etch, so we should let them upgrade to Lenny first and migrate to 3.6 afterwards + the version chosen affects at least /usr/share/request-tracker3.*/html (symlinks?) and the version of rt-setup-database used - the rt-setup-database stuff is run on first install and the 2.0 -> 2.2 migration script is run on upgrade + possibly ask permission (low priority) from the user before doing these? + we should handle gracefully the case where the database is already set up / upgraded, ie. make the database touching code idempotent + it may be necessary run rt-setup-database on upgrades too, since the current rtfm package doesn't do this automatically on install. The need for this should be detected automatically. + if an operation fails, bail out and tell the user to fix things (most probably configure RT itself first) and then retry manually I don't have any code for this yet, it's all vapourware. Help is welcome. The pkg-request-tracker-maintainers list should now be subscribed to the rtfm package, so no need to Cc. Cheers, -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
