[Note: please CC me if needed, I'm not subscribed to debian-apache]
Hi,
just looking at the wiki, I see:
====
Likewise, in postrm do upon purge:
if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
/usr/share/apache2/apache2-maintscript-helper apache2_invoke disconf yourapplication.conf
fi
====
Should not this be done on remove (and not purge)? Usually, when a
webapp package is removed, its configuration should be desactivated, no?
Regards,
Vincent
Le 22/03/2012 01:05, Stefan Fritsch a écrit :
> This is the first "Bits from the Apache Maintainers" announcement ever. There are lots of changes coming up and following a well- established practice we are going to announce some of them here.
>
> In this update: - New Apache HTTPD 2.4 available in experimental <HTTPD24> - Package Transition <TRANSITION> - Packaging Guidelines <GUIDELINES> - Call For Help <HELP>
>
>
> New HTTPD 2.4 available in experimental <HTTPD24> =================================================
>
> A major Apache HTTPD upgrade has been released in February. A brief overview of new features is available at [1]. Some of the changes have major impacts of the Debian packaging. Notably, all Multi Processing Modules (MPM), which were compiled as separate apache2 executables previously, can now be loaded as simple modules. This implies that the conflicting MPM packages like apache2-mpm-prefork are gone. Instead, users can pick the MPM they wish at runtime in future. Moreover, there some incompatible changes in the configuration which makes it likely that local configuration files have to be adjusted. Please see our changelog, the NEWS, and the README.Debian [2] files for more detailed instructions. More upgrade hints can be obtained upstream at [3].
>
> Thanks to a lot of work by Arno Toell, an experimental apache2 2.4 package is available in Debian's Experimental branch for most architectures (and the rest will be built soon). We invite everyone to test our package, but it is of course not ready for use in a production environment. We advise you to test upgrades and report any problems you faced. That said, please keep in mind that this upgrade will break any installed third party modules (mod_php, ...) unless the respective maintainers do provide an experimental package linked against Apache 2.4, as well. Some changes such as the default out-of- box configuration we intend to ship with Wheezy's 2.4 package are not finalized yet and will be addressed in another follow-up upload to experimental and/or unstable in the near future.
>
> Beware: The ITK MPM is not included for the time being. This may or may not change until the freeze.
>
> [1] http://httpd.apache.org/docs/2.4/new_features_2_4.html [2] </usr/share/doc/apache2/README.Debian> [3] http://httpd.apache.org/docs/2.4/upgrading.html
>
>
> Package Transition <TRANSITION> ===============================
>
> The new upstream release breaks the Application Binary Interface (ABI) for the first time since Debian featured the 2.2.3 package in Debian Etch. Thus, all reverse depending packages need a sourceful upload. To track the progress, we filed a transition bug in #661958. Refer there for a verbose description what we plan to do. In short, there are several things packages need to be aware:
>
> * The apache2 2.4 source package features an incompatible ABI ("module magic number") to all existing Apache 2 module packages. We've made a list of affected packages in the the denoted transition bug. All module packages need a source(!) transition. This is mostly because we expect module packagers to depend on our virtual API package in future, instead of declaring unversioned dependencies against our meta-package. There is a new dh_apache2 helper to help creating this dependency. Moreover, we have dropped the apache2-threaded-dev and apache2-prefork-dev development packages. Instead all packagers should build depend on apache2-dev only. Please refer to the <GUIDELINES> section for detailed packaging guidelines * Please review whether your module packages are still needed, or if a similar or roughly identical functionality is provided by a new core module. * If a module package does not build with 2.4 and there is no new upstream version that does, it may be time to ping
the upstream developers. If upstream is inactive and/or you have difficulties getting the module adapted to 2.4, feel free to contact us. Some hints can be found at [4]. * The handling of modules that only work with a particular MPM is not yet finalized. At the very least, such modules should refuse to load with an incompatible MPM and print a meaningful error message. * We want to consolidate reverse dependencies of web applications. See <GUIDELINES> as well. * We plan to do a mass-bug-filing by the time we consider the package ready for unstable. Following our time line we hope to upload to unstable early in April.
>
> [4] http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html
>
>
> Packaging Guidelines <GUIDELINES> =================================
>
> We've written packaging guidelines how we would like reverse dependencies to declare their package relations to our binary packages. These guidelines are not yet set in stone. Especially for the parts concerning webapps we encourage discussion. Refer to [5,6] for the details. In a nutshell:
>
> Module packagers need to change build-dependencies and test their modules against Apache 2.4. Build-depend on "apache2-dev" unconditionally (apache2-threaded-dev and apache2-prefork-dev are gone). Binary module packages must not depend on apache2 or apache2- bin. Instead modules must depend on our virtual API package (apache2- api-20120211) only. This should make things easier for the next major upgrade.
>
> Packagers of web applications with configuration files (e.g. files installed to /etc/apache2/conf.d/) should note that the right directory for these kind of configuration files is now /etc/apache2/conf-available. Moreover, web applications should not declare dependencies against the apache2 HTTP server only. Many web applications may work with other web servers, too. Therefore they should recommend(!) supported alternatives by declaring packaging relationships like this:
>
> Recommends: apache2 | other_web_servers_you_support | httpd
>
> Note, we do not have a strong opinion whether to put web server dependencies of web applications to a hard dependency or a recommendation. We would like to hear your feedback on that - especially if you are maintaining another web server or a web application in Debian. Generally, we are keen to consolidate a uniform and predictable behavior for all web applications but we do not want to push any decision in one or another direction. For more context on this discussion please see [7].
>
> Please do not call our configuration wrapper scripts (a2enmod/...) directly. Instead use our maintscript-helper which is designed to do things in a way we would like reverse dependencies to interface with us. It is planned to allow the administrator to configure what should or should not be done. Again, see [5,6] for detailed instructions. Also, read our hints carefully, as some web applications should not have a hard depdendency against our web server. This case must be covered in your maintainer scripts.
>
>
> [5] http://wiki.debian.org/Apache/PackagingFor24 [6] </usr/share/doc/apache2/PACKAGING> [7] http://lists.debian.org/debian-devel/2012/01/msg00148.html
>
>
> Call For Help <HELP> ====================
>
> You would like to help us? We can still use help, especially for the 2.4 transition. There is our RFH bug #646208 still left open and there is a wiki page [8] with our ongoing and upcoming changes we plan to work on.
>
> [8] http://wiki.debian.org/Apache2Transition
--
Vincent Danjean GPG key ID 0x9D025E87 vdanjean@debian.org
GPG key fingerprint: FC95 08A6 854D DB48 4B9A 8A94 0BF7 7867 9D02 5E87
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo: deb http://people.debian.org/~vdanjean/debian unstable main