[Pkg-torrus-maintainers] Help with torrus 2.01?

[Bernhard Schmidt]

Am 16.09.2011 09:09, schrieb Marc Haber:

>> 1.) Upstream recommends using the FastCGI method for new
>> installations, which has been causing a lot less problems than
>> mod_perl in my experience. However, old installations will continue
>> to use the old method. I don't see a way to migrate automatically.
>> Should we
>>   - not do anything
>>   - add a note in NEWS.Debian and hope for people to see it
>>   - add a debconf note
>>   - ???
>
> Can we have packages that
> - use fastCGI on new installs
> - continue using mod_perl on updates,
> - make migration from mod_perl to fastCGI as easy as possible,
> - document this in NEWS.Debian?

Should be possible, at least for now. Everything necessary for FastCGI 
is in the -common package (except for the FastCGI server of course), 
people using torrus-apache2 will continue to use mod_perl. If they want 
to switch, they need to configure their server for FastCGI and then drop 
the -apache2 package.

It would only get complicated if we wanted to migrate -apache2 to 
automatically use Apache2+mod_fcgid at some point, but to be honest I 
don't think it is worth the hassle. FCGI-Configuration is about five 
lines of Apache config, and there are way more FastCGI servers out there 
to be used. I'd point users to the documentation and be done with it.

>> 2.) Upstream strongly recommends rerunning devdiscover and recompile
>> the database on upgrades. I don't want to open the can of worms
>> associated with an automated devdiscover, but recompiling the
>> database would be possible. However, it can take literally ages to
>> complete, doing that in postinst would be highly annoying since a
>> lot of other services might be down during that time when running a
>> dist-upgrade. So what to do?
>
> If torrus continues to run without a recompile in the majority of
> cases, we should not do anything in the maintainer scripts. In my
> experience, torrus updates were never a smooth thing due to Berkeley
> DB breakage, so I reckon that user will be conditioned to read docs
> and check torrus after upgrade anyway.

I have no idea whether it will continue running. I haven't tried a major 
upgrade yet. Especially not in conjunction with a dist-upgrade where the 
libdb-version also changes.

I'm considering running the db-recover script on upgrades, any objections?

>> 3.) torrus-fastcgi is currently an extremely small package with a
>> dependency on a 200k perl module, shipping the 2k fcgi-handler
>> script and recommending a few (but by far not all) FCGI-webserver
>> implementations. IMO, this does not warrant an extra package. Should
>> we fold it into torrus-common?
> We should, IMO.

Ok.

Bernhard