Bug#664761: apache2/conf.d migration: what should webapp packagers do?
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 -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140721214605.gy12...@google.com
Bug#664761: apache2/conf.d migration: what should webapp packagers do?
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 signature.asc
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 -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140714211220.gh12...@google.com
Bug#664761: apache2/conf.d migration: what should webapp packagers do?
Jonathan, we're approaching Sid so I'm coming back to your bug. Do you have any suggestion what you'd like to read in the NEWS file? As I read the remaining discussion of this bug, I think everything else was clarified already, right? -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D signature.asc Description: OpenPGP digital signature
Bug#664761: apache2/conf.d migration: what should webapp packagers do?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Jonathan,
it's me again. We've written the promised mail to
debian-devel-announce including pointers to the wiki with hands-on
tutorials how to reverse packagers should interact with us. Is this
somewhat what you expected to read?
For your question in particular:
On 20.03.2012 18:18, Jonathan Nieder wrote:
/etc/apache2/conf.d/gitweb:
Alias /gitweb /usr/share/gitweb
Directory /usr/share/gitweb Options FollowSymLinks +ExecCGI
AddHandler cgi-script .cgi DirectoryIndex gitweb.cgi RewriteEngine
On RewriteCond %{REQUEST_FILENAME} !-fuld RewriteCond
%{REQUEST_FILENAME} !-d RewriteRule ^.* /gitweb/gitweb.cgi/$0
[L,PT] /Directory
I do not think having a global /packagename is a problem either. If
the user does not like it, he can always change it. That's what
configuration files are for.
However, reading your snippet I realized, you use module directives
which aren't available until one enables the rewrite module in your
case. We might think how to allow packagers of web applications to
tell us, your configuration needs a special module. As we wrote in
the announcement mail, we're open to suggestions from packagers of web
applications.
I guess we may provide another helper function you can call or we
stick to apache2_invoke enmod mod1 [mod2 ...].
From the PACKAGING file I get the impression that I should rename
the
gitweb configuration (with the usual conffile renaming dance) to
/etc/apache2/conf-available/gitweb.conf, depend on an updated
apache2, run
[ -e /usr/share/apache2/apache2-maintscript-helper ] || exit 0 .
/usr/share/apache2/apache2-maintscript-helper apache2_invoke enconf
gitweb
in postinst configure, and ask for a Breaks from the apache2
maintainers. Is that right?
That's (somewhat) right. We encourage you not to declare unconditional
package relations to apache2. Instead, you should declare relations
in the form
Recommends: apache2 | http
That's why you need to protect the calls to
/usr/share/apache2/apache2-maintscript-helper. Whether to use depends
or recommends is subject to discussion, and we'd like to hear web
application packagers' opinion on that.
Alternatively you can use dh_apache2 (presuming your configuration is
in debian/gitweb.conf):
debian/gitweb.apache2:
confdebian/gitweb.conf
debian/control:
Build-Depends: dh-apache2, debhelper
...
Recommends: ${misc:Recommends}
This bug report is a request for advice in NEWS.Debian.gz about
this, for example by including a pointer to PACKAGERS in the text
and mentioning whether packages supporting old and new apache at
the same time are possible.
I am not sure whether the NEWS file is an appropriate place for
packaging hints but I will think about.
Similarly, I will think whether we will give hints to support both
configuration styles at the same time. In the end, we do not intend to
ship apache2 2.2 in Wheezy.
- --
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJPaxmlAAoJEMcrUe6dgPNtCZQP+QFl2PhCZ1bKXfz50crAGn5S
nLS4rDTY1xJDV0d+OL7o+ecYyK3l6FSD1QW7L1XSZ03K1MtG1AJx9zxNK2BCV6cQ
V+tyFFArgLK8iXKuXJDbma9XIxkTFXmIwYgE6I1+rsrfKb4pjqXn7JJOh7ZrfNU3
stjJzN+bSgUKUwQEXUogoDYHGs4ED6gUmK9NoU2zaN5Y8WuB1T/it5U8f+4rNEhb
XCuZLYnTeQzt6OuQsMHJaSFz/pO3zobhu9sSQJLPmzbNtEuGOYOO5HP22WeDbQHS
SEK3YtTQXCsjJHOAo4XPBJ27i9LGBdQ4xai3Xclfbiiz+ggNboCSdY3maYA4OqSW
ApWuWd/S6jFN6A24fSWPUoRmLYCHBpM8thZNiKLqL+V6dCHrqagGq1xZWpmKxksI
0407HidM4JAhY2sN4w3/6jysoWCDtdeonjX7ZdRWdOryonWFCzjYTm/YPZnUSfP+
l4/fAnQHLI0LSk5b0uBpwY1/sqRKGUbnyg3ndSLNnseBrHbkmiyzEjBnqIvGPD08
Br235WVgZ3Ye2mqtqZGJHyocn9mXPmwxxGjFqR5hk0R4jTBbBASogOHEQcAxJPnm
HnDXaS18MSiCZdmeGOq2zdDmYaoon9/WfkOWwS53x+/kHUvQIXYwr0zdwd9nyWGi
q2ljL6386hTnsW1ib+K1
=Rwvk
-END PGP SIGNATURE-
--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f6b19a5.9010...@toell.net
Bug#664761: apache2/conf.d migration: what should webapp packagers do?
Arno Töll wrote: However, reading your snippet I realized, you use module directives which aren't available until one enables the rewrite module in your case. We might think how to allow packagers of web applications to tell us, your configuration needs a special module. As we wrote in the announcement mail, we're open to suggestions from packagers of web applications. My bad --- I realized too late I had sent my local configuration. The actual snippet is Alias /gitweb /usr/share/gitweb Directory /usr/share/gitweb Options FollowSymLinks +ExecCGI AddHandler cgi-script .cgi /Directory Ideally the pathinfo stuff should be conditional on whether the rewrite module is already loaded. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120322134624.GA16653@burratino
Bug#664761: apache2/conf.d migration: what should webapp packagers do?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22.03.2012 14:46, Jonathan Nieder wrote: Ideally the pathinfo stuff should be conditional on whether the rewrite module is already loaded. That's reasonably easy to achieve: IfModule mod_rewrite.c RewriteEngine on RewriteRule [whatever] /IfModule Hard dependencies are more tricky to resolve. - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPay8cAAoJEMcrUe6dgPNtIP0P/R8qNMx8smtCAElfFSazppqO 3hLm7M+aAbTHGMaB+gUwfEyr805Hf6G+5F6++7Cxe8WAccFpu2v2I1jhzzpmuIK+ HgiXfsIi7Kv72E6HiYflhWUkwhMA67lwP/0uf9E5BUPqZkneYMNHGjFHKOCH5O2A LFQyfAFOsVvpw2U8zjeDzydKEIkI7vhQs5YE3A/wSlIkC9d3nnLOfHxReHGFLQ7l 0KzsCQs0AIz6LQoMSo6MVjtqO57KeHHBpPRsWB31e0W/vq7gxQ4V9r9njFCiG09m HzD6/y4bNU4tL3SnPSj9DAwSUMW4AN6q63yfAM39JbJ3DZVPa3tjh08xh73q6Axy VHtqMh18CiuWF6O/d49vsdxTGNVsXlBY2gxYXSVPdmhZ40VB5nE2G8k1XUBh655v 7n9MqG/S+5IBgfyLZGhILJT9ZNQ7BqW8NJMZHH0kaUSzEh32reVYALikgWIDogJN cMQFJ3QINO/Xvd1wxzD0E+37/BlZV52OmG19DsrpBo7w8K/gCeCu2t12Lw/MmQ/2 Sw3aS4tIaGAYl0uNcjTNXCd8RvPEm2ollLwYtbmioOfBp5bHx9HtaC6fJe7reHh5 Vig1eyO1ccU+bM2op2yVkzi9zWsys3PV/OLrh8kwSymL6AZ+qTPlE5xO46dLShAT PQh/MOZPav6DnucXtxht =0omo -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f6b2f1c.6020...@toell.net
Bug#664761: apache2/conf.d migration: what should webapp packagers do?
Arno Töll wrote: I am not sure whether the NEWS file is an appropriate place for packaging hints but I will think about. I think a brief mention would be useful for sysadmins with local packages who do not necessarily follow debian-devel-announce. Similarly, I will think whether we will give hints to support both configuration styles at the same time. In the end, we do not intend to ship apache2 2.2 in Wheezy. For gitweb, it would be very useful since it would let us adopt the needed changes early (possibly even before an updated apache migrates to sid) and keep the sid package installable on squeeze. Thanks, Jonathan -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120322144536.GD16653@burratino
Bug#664761: apache2/conf.d migration: what should webapp packagers do?
On Wednesday 21 March 2012, Paul Wise wrote: On Wed, Mar 21, 2012 at 1:18 AM, Jonathan Nieder wrote: Upgrading apache2 to the version in experimental breaks my local gitweb installation. Gitweb ships the following snippet in /etc/apache2/conf.d/gitweb: Alias /gitweb /usr/share/gitweb That looks like a highly inappropriate thing for gitweb to be doing. There is no way for the package to know what URL and filesystem paths (for data/config) the sysadmin wants gitweb to be installed at. The package needs to ask the sysadmin if they want to setup any instances, prompt them for the relevant data and run any scripts needed to create those instances. I think its not that bad. For a significant part of the users, /gitweb as urlpath is ok. And the apache config snippet is a conf file, so changing the URL path is very easy. What is bad is that it is visible in all vhosts, but that's something we intend to make configurable in the apache2 2.4 packages. About the repository paths, those are configured in /etc/gitweb.conf. I don't think that a web app as simple as gitweb needs to ask things during installation. -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201203212203.13735...@sfritsch.de
Bug#664761: apache2/conf.d migration: what should webapp packagers do?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Jonathan, On 20.03.2012 18:18, Jonathan Nieder wrote: In the new world order, as a packager of a webapp, what should I do to bring those goals about? Please be patient. You're just to fast. We've been scheduled a d-d-a mail with instructions for later today :) - -- with kind regards, Arno Töll IRC: daemonkeeper on Freenode/OFTC GnuPG Key-ID: 0x9D80F36D -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPaL8HAAoJEMcrUe6dgPNtEkUP/0AnbMxMGz/xnO56Uyd0vyly 3a31S+rAiIeV2JIIEV7RXA742ZHxTvuF7GLjIM5cTj9jxkh+QdssVeQ9rc1ndT/D xXur/03NpP1UNeGXpf2V0W4g/LZmkL/tbOEB+GdzuLGaAp+NdIP03HLidiPMzTZn lAbLWMe9WVHDiaZnxGKqszFpOLo120lYgUiDyqW58j4ooFfn9C2TAVM2ex1bxeAM 0Uz5nRyj+KEsukqT41QmBULW20rxpo0p11xG9dSl+qxgsBSwCtZJGlcLWVlbrzK0 Z3xw8TdtOgSwsN5dgG47tHqRmGPTkmhEDRAmSGx/e7yRzIk3S82gTcvTf56Yt2TW 3SWSBFCgv27Gbi3Qth0xRNEAOzyk9wVfJmvy73hW3rYWfSr4H+IRcOGGYIztxJ5K 59xxneE6nlE+V3a0KcuJi5WxjaAbpB8j0bs5KFoLxhWA4lymHgrOSBoZrbHE1WdV Vq0SVVb0y1ZsJWy7rfMVIl+wCcB3Bz5abvUGDTchpGWsuRwTBM62HOzYDgMe2/Rd t4A8KZ+o0S96+Exc8j9fY1HVHwr0/jeycCFnCvnZlHYBweSZoSP6MBwCZN570YCX mmSskc8Yasfda0Oy/CrGFPCuhgqocj+6xToDMIidpLFUWw1DIFKP+9tyMx3ifoSo CULvMdUGR/jFa2roMGgk =H/EG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f68bf07.3090...@toell.net
Bug#664761: apache2/conf.d migration: what should webapp packagers do?
On Wed, Mar 21, 2012 at 1:18 AM, Jonathan Nieder wrote: Upgrading apache2 to the version in experimental breaks my local gitweb installation. Gitweb ships the following snippet in /etc/apache2/conf.d/gitweb: Alias /gitweb /usr/share/gitweb That looks like a highly inappropriate thing for gitweb to be doing. There is no way for the package to know what URL and filesystem paths (for data/config) the sysadmin wants gitweb to be installed at. The package needs to ask the sysadmin if they want to setup any instances, prompt them for the relevant data and run any scripts needed to create those instances. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6Gb_wyOcNm\vfs-ed42jpf9j4msbrneuhikyulpo...@mail.gmail.com
