Bug 225005
| Summary: | Mk/Uses/apache.mk: Rework 3rd party module building | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Miroslav Lachman <000.fbsd> |
| Component: | Ports Framework | Assignee: | freebsd-apache (Nobody) <apache> |
| Status: | Closed FIXED | ||
| Severity: | Affects Many People | CC: | brnrd, clement, eugen, joneum, ohauer, pi, ports-bugs |
| Priority: | --- | Keywords: | needs-patch |
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Miroslav Lachman
2018-01-08 16:59:14 UTC
It seems we need clarified policy for maintainters of Apache modules that should describe how to deal with modules on deinstallation/upgrade to not break things and not ruin user-modifien configuration files. Such policy needs to be consistent with code of ports/Mk/bsd.apache.mk. Do we already have such documentation for maintainers? The problem is that current code in ports/Mk/bsd.apache.mk is buggy - as I demonstrated above, mod_xsendfile does not use any own code for handling httpd.conf modification, it uses just these variables in Makefile: USE_APACHE= 22+ AP_FAST_BUILD= yes AP_GENPLIST= yes Everything else is in bsd.apache.mk and as shown above it will remove my modified settings on upgrade. (In reply to Miroslav Lachman from comment #2) Can you propose a fix to that code? (In reply to Eugene Grosbein from comment #3) Sure, I can try to write something but I don't want to spend time writing something which will not be considered useful and commitable. So can we first choose what the right method should be? 1) do not touch httpd.conf at all and just print pkg-message instructions to users or 2) create module_name.conf.sample in apache24/modules.d/ Which one is preferred way? (In reply to Miroslav Lachman from comment #4) The port www/apache24 already installs *.sample configuration files consistently with Porters Handbook, so that should be just fine. Some additional hints in pkg-messages won't hurt too, so you can do both ways, if you wish, but *.sample's are needed anyway. (In reply to Eugene Grosbein from comment #5) OK, I'll try to code something in the next week (if time permits) Thank you. please note: https://reviews.freebsd.org/D12308 Here we are currently in the last final tests I've heard discussions of moving module configuration to something like modules.d to cope with these changes. With the migration to USES behind us, we could start working on this. I like the idea of making this more modular. Any tips/hints? (In reply to Bernard Spil from comment #8) What is the current state? Are there consensus to user module_name.conf.sample in apache24/modules.d/? If yes, then I would like to see all apache modules converted to install sample file instead of touching httpd.conf unconditionally. I was on vacation and then busy with $WORK so I didn't touch this PR for a while. Do we have something in ports/Mk/ to handle installing sample files for Apache modules or do we need to code something? (In reply to Miroslav Lachman from comment #9) > would like to see all apache modules converted I assume you refer modules not from the www/apache24 only? I believe there's some form of consensus on using modules.d, I for one would be happy to support that. Beware that a number of modules are on the verge of having to be deleted, as they are 2.2 only. See https://wiki.freebsd.org/Apache#Apache_2.2 Additional change is that we'll need to add an Include modules.d. Personally, I like to set Global Defines outside of the config and include that for paths I want to use SSLDir, LogDir, ModConfDir ... Just read your post to freebsd-ports@ from 2017-Nov.
I can see us adding mechanism to Mk/Uses/apache.mk to build modules.
Thinking up to now...
Add arg module to USES= apache to signal that we're building a module. This would also allow us to document more closely.
AP_FAST_BUILD to be renamed and used as auto-build and install mechanism. It is not FAST, just an easier template for plist generation and installation.
Install is using @sample to install into modules.d and echo message on enabling.
modules.d files can also use @sample template as they should adhere to
> # LoadModule modname
> <IfModule modname>
> ModuleConf here
> </IfModule>
to force it not to auto-load include not fail after installation.
The whole ap-gen-plist target could possibly disappear by using PLIST_FILES instead.
mod_phpNN is a difficult one altogether, it should be ap24-mod_phpNN (or ap22-mod_phpNN) but I guess that'll break lang/phpNN's Makefile.
Bernard (with hat apache@)
A commit references this bug: Author: brnrd Date: Sat Mar 24 22:01:35 UTC 2018 New revision: 465488 URL: https://svnweb.freebsd.org/changeset/ports/465488 Log: www/mod_md-devel: Add missing files - Pulled the trigger early on 465487 PR: 225005 Changes: head/www/mod_md-devel/files/999_mod_md.conf.in head/www/mod_md-devel/files/patch-src_md__crypt.c head/www/mod_md-devel/files/pkg-message.in head/www/mod_md-devel/pkg-message head/www/mod_md-devel/pkg-plist Why is this closed without a commentary? (In reply to Eugene Grosbein from comment #13) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225005#c12 (In reply to Jochen Neumeister from comment #14) I fact, that commit r465488 has no connection with this PR. Are you sure you understand the matter? That bug was closed, but it should remain open as the issue is no fixed yet. I've added support to mod_md-devel and mod_http2-devel. Numbering the .conf files was a complete guess. How do we go about numbering these properly? If we figure that out, we can go and add support to the ports. Now that nothing has happened here for two years, I'm closing down. If the problem still exists, please open with a current error description. |
