[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



reopen 664761
block 669292 by 664761
quit

Hi Arno,

Arno Töll wrote:

> In lack of responses, I assume that all your questions have been
> answered or properly addressed.

Alas, no.  Since message #58 wasn't cc-ed to me, I didn't see it.

https://wiki.debian.org/Apache/PackagingFor24 is helpful (thanks!),
but I'm still stuck --- I really just don't know how to package gitweb
in the new setup.  See also http://bugs.debian.org/669292#28:

 * It's not clear when to run "apache2_invoke enconf gitweb" for a
   package like gitweb that does not have a Depends against apache
   2.4.  If I run it conditionally based on the Apache version, then
   gitweb will still be broken when the user upgrades apache, unless
   gitweb happens to be upgraded later in the same upgrade run.

 * It's not clear when to run "apache2_invoke disconf gitweb".  At
   "remove" and "purge" time doesn't seem to be enough.

And https://bugs.debian.org/cgi-bin/bugreport.cgi?msg=23;filename=update-apache-packaging.patch;att=1;bug=669292:

 - prerm deconfigure does not clean up as much as it should
 - needs triggers to reconfigure when apache is updated?

Basically, I am stuck on understanding the state machine:

 (1) What is the intended update order between webapps, apache-common,
     and apache itself?  What Depends, Pre-Depends, or triggers should
     be used to make sure everything works okay regardless of the
     update order?

     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.

 (2) What is the intended uninstallation procedure?
     https://wiki.debian.org/Apache/PackagingFor24 tells me I should
     enconf in postinst and disconf in postrm.  That's confusing
     because:

     * Usually in packaging, postinst is a mirror image of prerm so
       when the package is in a given dpkg state, the state of
       configuration matches that.  Why here is postinst's mirror
       image in postrm instead?

     * Dependencies are not guaranteed to be present during postrm, so
       the disconf is not guaranteed to happen.

Thanks,
Jonathan


Reply to: