Hi Jonathan,
On 14.07.2014 23:12, Jonathan Nieder wrote:
> 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.
web applications aren't supposed to depend on Apache anyway. We suggest
packagers of web applications to recommend on Apache so that other web
servers can be used, too if people wish. On that matter I do not think
gitweb would be different to other packages, or is it?
Therefore, we recommend that you check if Apache 2.4 is installed at
time you execute the maintainer scripts. There is not much you or we
could do, if it isn't. We do both agree that gitweb should rather not
depend on Apache, therefore we need conditionals in maintainer scripts.
For Apache 2.4 this works like this:
if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
. /usr/share/apache2/apache2-maintscript-helper
apache2_invoke enconf gitweb.conf || exit $?
fi
This ensures that your configuration is enabled when Apache is
installed, and it will not fail if it is not. You do not need to worry
in what context to execute this, as our apache2-maintscript-helper takes
care to figure out the right thing in the right context (e.g. postinst
configure).
> * 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?
For the archives: apache2-maintscript-helper is reading the maintainer
script state out of $@ supplied to your script. If you wish to call it
from a function, you must ensure the context is preserved.
If you wish, you can set APACHE2_MAINTSCRIPT_DEBUG (e.g. in
/etc/apache2/envvars) and get debug output of the
apache2-maintscript-helper at runtime to see what it does in various use
cases.
> 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?
Not sure what you ask me about here?
> 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?
Please read
http://anonscm.debian.org/gitweb/?p=pkg-apache/apache2.git;a=blob;f=debian/PACKAGING;h=0bbb06c48d628cd7c3b6037a0118574a722f2184;hb=HEAD#l157.
Does this answer your questions? It does not talk about triggers,
because there are none (though we planned to do at some stage) ;-)
> 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.
> (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.
>
It is actually preferred that disconf is called in prerm. This is also
what dh-apache2 would do if you let it. Or in both scripts. I am not
sure why this is isn't written more explicit in the wiki but I will fix
that in a minute.
--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
Attachment:
signature.asc
Description: OpenPGP digital signature