Chris H wrote on 10/18/2017 19:25:
On Wed, 18 Oct 2017 02:16:37 +0200 Miroslav Lachman <000.f...@quip.cz> wrote
Installing a Module would:
o search for the Module line in httpd.conf (commented/uncommented)
o create a commented line (if not exist)
o present a banner regarding the [httpd.conf] line
I agree with this.
DeInstalling a Module would:
o search for the Module line (commented/uncommented)
o nuke the line (if exists)
o produce a banner regarding what happened
I don't think this method is too intrusive (regarding httpd.conf)
because if the Module line doesn't exist; placing a commented line,
and providing a banner as to how to Activate it, is/should be expected.
OTOH removing a Module line on a Module you are UNinstalling should
be expected; as the Module no longer exists, and can no longer be
enabled. This process should also present a banner, as to what just
occurred.
But there is a big problem on pkg upgrade which means deinstall +
install. All users of some module are left without this module after
simple pkg upgrade and this is bad. It is the same as if 'pkg delete
apache24' deletes whole httpd.conf which it does not if it was modified.
That's why I propose
DeInstalling a Module would:
o search for the Module line (commented only)
o nuke the line (if exists and is commented)
o produce a banner "You may need to manually remove LoadModule
mod_whatever if it is no longer needed."
pkg upgrade should leave the machine in working state just after restart
of upgraded services. No need to re-enable some module again and again
after each pkg upgrade.
Plain pkg upgrade should not revert any changes in config files which I
did on purpose.
Miroslav Lachman
_______________________________________________
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
