[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 [email protected]
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
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: http://lists.debian.org/[email protected]
