Bug#664761: apache2/conf.d migration: what should webapp packagers do?

[Jonathan Nieder <jrnieder@gmail.com>]

Arno Töll wrote:
> On 14.07.2014 23:12, Jonathan Nieder wrote:

>>  * It's not clear when to run "apache2_invoke disconf gitweb".  At
>>    "remove" and "purge" time doesn't seem to be enough.
>
> Likewise as for the enable part. Just call
> 
>     if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
>         . /usr/share/apache2/apache2-maintscript-helper
>         apache2_invoke disconf gitweb.conf || exit $?
>     fi
>
> ... and apache2-maintscript-helper tries to figure out when to do what.
> In particular we disable the module in postrm purge, postrm remove and
> prerm remove. When else do you think it would be necessary?

As you noticed below, I didn't realize this should be called in prerm
too.  That helps.

I think 'prerm deconfigure' needs the same treatment.

[...]
>>      In particular, the conditional enconf and disconf invocations
>>      seem to make it easy to get into a non-working state and never
>>      get out of it.
>
> Well, we need to deal with that. This is not different than before. If
> Apache2 wasn't installed, you putting a conf to conf.d is not going to
> work out either. If you meant to address situations when you install
> your conf to conf-available and install Apache at a later stage, it is
> our business (i.e. Apache maintainer's) to ensure those get enabled
> then. That's a good point actually, and I need to think if we can and
> should do something in that case.

Yep, I am worried about that case and the case where a webapp's conf
is enabled and then Apache is deinstalled before the webapp is
removed.  If webapps can trust Apache packaging to automatically
enable things when apache2 is installed and disable them when it is
deinstalled (or if they can treat the lack of such behavior as
Somebody Else's Problem :)) then I'd be all set.

Thanks,
Jonathan