[request-tracker-maintainers] Bug#434270: rtfm: request-tracker3.4 is going away, upgrade to the rtfm 2.2 series is necessary

[Niko Tyni]

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   ntyni at iki.fi