[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#226833: apache: modules-config fails on unrelated .so files



Hi Simon,

On Thu, 8 Jan 2004, Simon Huggins wrote:

> Package: apache
> Version: 1.3.29.0.1-3
> Severity: normal
>
> modules-config is overzealous in its parsing of /usr/lib/apache/1.3 on
> upgrades.
>
> My previously working config caused it to die during configuration.
>
> I had an old libperl.so lying around in there (I'm still not sure why -
> I don't have mod_perl installed now).
>
> It didn't have a .info file so modules-config barfed.

The error is generated on purpuse. It doesn't barf.

> I don't think modules-config should just barf on such things.  I'm not
> sure if you're allowed to prompt during configuration I believe it's
> frowned upon but as you're going to barf anyway perhaps it would be
> permissible to prompt the user to override its choices.
>
> Otherwise perhaps it could limit itself to complaining about currently
> active modules or just discard modules from its own calculations which
> don't have an info file (and warn presumably).

There are reasons why we stop upgrading if the relation between .so and
.info is incosistent. The problem is simple, without info file we cannot
build the list on modules that needs to be loaded. If for example we
ignore a module, and some directives of this module are in the
configuration files, apache will complain at a later stage that the
configuration is broken (when we perform the restart) and it will not
attempt a restart. This can lead to a situation in which the user will
think that the upgrade was smooth when it wasn't, with an old apache
running and the new one not completely configured. Or that apache is not
running and it will not restart "without an explicit reason" that is not
the simplest to debug.

Fixing this problem would make user life more complex in terms of
understanding what is wrong.

>
> Either of these would have given me a nicer upgrade path.

In your specific case this is possibly true but not for common cases
therefor is much better to stop upgrading with an error and let the user
know that something is missing or broken and that the upgrade is not
complete other than just hide things from him.

The idea of giving the user the possibility to override is nice but
extremely dangerous for the same reasons as above.

In anycase i will close the bug in a few days if you do not have any more
comments.

Fabio

-- 
Our mission: make IPv6 the default IP protocol
"We are on a mission from God" - Elwood Blues

http://www.itojun.org/paper/itojun-nanog-200210-ipv6isp/mgp00004.html



Reply to: