On Mon, Jan 19, 2004 at 01:02:07PM +0100, Fabio Massimo Di Nitto wrote: > On Mon, 12 Jan 2004, Jeroen van Wolffelaar wrote: > > Amongst others, config files were already split up. For example, I had > > moved all LoadModules line to a file called /etc/apache/modules.conf > > > > After upgrade to this version, the postinst failed, because apache > > failed to start because some modules I enabled via modules.conf were > > missing. > > If they were all debian modules it is kinda strange otherwise yes.. > > > I'm now going to clean up the mess and restore config from backup, and I > > will check out the postinst afterwards, if I find more problems, or a > > patch for this, I will add to this report and/or open another one. > > No need to. I know where the problem is (unfortunatly).
Ok, that's half of the reason I didn't yet do so (other reason: RL) I noticed the problem, IMHO is in the cp -f modules.conf modules.conf.old without any checking wether old exists, so only keeping one backup (and on postinst rerun original modules.conf is lost). > > Above this, why modules-config? You cannot add comments next to the > > loadmodule line like this?! > > sorry but i don't understand what you mean. Without modules-config, you can maintain a configuration fragment with the LoadModule lines, and have comments above them, as a kind of reminder for yourself: what is it, what's it relevance to my own system, and why did I disable/enable this module. With modules-config, that is AFAICS impossible. > > apache2's approach of a mods-available, and mods-enabled containing > > symlinks to the former, MUCH cleaner, and easier, and more > > straightforward, and non-causing-data-loss! And, it's more consitent > > within Debian > > The switch to modules-config and modules.conf is part of the transition. > There are several steps that needs to be done and cannot be done in one > shot. > > the first one was to get rid of the old apacheconfig that was pretty much > broken, replacing it with modules-config forcing all the apache modules to > clean up the way they were configured. Providing a standard (and only one) > way to enable/disable modules. Once this is completed we can change > modules-config and the underlaying structure without the other modules > even noticing it. the advantage is that at that point we can make a clean > transition without having to upload 200 packages together with 200 > different implementations to achieve the same task. For the disadvantegs > just check the BTS ;) Okay, I agree & understand here :), thanks for the explaination. So I understand you will in the future mimic apache2's way of handling apache-modules? I believe that would greatly improve Debian's consistency. My second issue with modules-config is in a different bugreport now on its way. > We can agree that the name modules.conf was not the best choise but (and i > accept my responsabilities for it) we endup in a urgent and broken upload > because of perl breaking the abi (at that time). I don't fully grasp perl's abi relevance here, but in fact, I disagree modules.conf is a bad name: _if_ it is decided to have a seperate file for the modules configuration, modules.conf seems very logical (this is emphasized by the fact that I personally had choosen that very name long time ago for this purpose). Unfortunately this clash caused this very problem to happen with me, but ... > well you are still running a testing/unstable system. things can break for > mistakes... tho noone want it. ... indeed, I don't blame anyone, my goal is to provide an as useful as possible bugreport to assist apache-maintainers fixing it in order to prevent this bug slip into sarge :) Sorry if I was unclear about this, and thanks for all the good work. --Jeroen -- Jeroen van Wolffelaar +31-30-253 4499 [EMAIL PROTECTED] http://Jeroen.A-Eskwadraat.nl
