Bug#227232: apache: Overwrites own modules.conf on upgrade
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
Jeroen@A-Eskwadraat.nl
http://Jeroen.A-Eskwadraat.nl
Reply to: