Re: Re: reallyall vs. all vs. most
I was just pondering this mod_log_debug myself on the Windows side. There, we have only what I would guess as the equivalents of Most and All. If I were the one who could make the decision I'd want it in Most (BuildBin). just my 2 pesos, Gregg -Original Message- From: Daniel Ruggeri drugg...@primary.net To: dev@httpd.apache.org Date: Tue, 05 Jul 2011 21:39:16 -0500 Subject: Re: reallyall vs. all vs. most I would also see a case for mod_log_debug to be in MOST. It's one of those modules that one wouldn't care too much about until it's needed. -- -- Daniel Ruggeri
Re: reallyall vs. all vs. most
Troll Default set of *loaded* mods is more important (Build many but load few by default) On Jul 5, 2011 5:22 PM, Stefan Fritsch s...@sfritsch.de wrote: On Tuesday 05 July 2011, Igor Galić wrote: even though it means that reallyall will yield different results on different systems That was the point of reallyall. Build everything that is possible with the installed dependencies. It wouldn't be very useful if you would need all kinds of weird third party libs to use it. BTW, I think it would be more useful if all enabled more modules. Basically what reallyall does except for examples, hard core debugging, very experimental, and very obsolete stuff. Here is what gets built for most (M) and all (A) and what I would like to change. The choices are certainly subjective, but I think there should be many changes where we all agree. So please comment. MA mod_access_compat MA mod_actions MA mod_alias MA mod_allowmethods MA mod_asis # remove from 'most' MA mod_auth_basic MA mod_auth_digest MA mod_auth_form MA mod_authn_anon MA mod_authn_core MA mod_authn_dbd MA mod_authn_dbm MA mod_authn_file MA mod_authn_socache MA mod_authz_core MA mod_authz_dbd MA mod_authz_dbm MA mod_authz_groupfile MA mod_authz_host MA mod_authz_owner MA mod_authz_user MA mod_autoindex MA mod_buffer MA mod_cache MA mod_cache_disk MA mod_cgid MA mod_data # remove from 'most' MA mod_dav MA mod_dav_fs MA mod_dbd MA mod_deflate MA mod_dir MA mod_dumpio MA mod_env MA mod_expires MA mod_ext_filter MA mod_file_cache # remove from 'most' MA mod_filter MA mod_headers MA mod_heartbeat # remove from 'most' MA mod_heartmonitor # remove from 'most' MA mod_ident # remove from 'most' and 'all' MA mod_imagemap # remove from 'most' and 'all' MA mod_include MA mod_info MA mod_log_config MA mod_logio MA mod_lua MA mod_mime MA mod_negotiation MA mod_proxy_express # remove from 'most' (?) MA mod_ratelimit MA mod_reflector # remove from 'most' MA mod_remoteip MA mod_reqtimeout MA mod_request MA mod_rewrite MA mod_session MA mod_session_cookie MA mod_session_dbd MA mod_setenvif MA mod_slotmem_shm MA mod_socache_dbm MA mod_socache_memcache MA mod_socache_shmcb MA mod_speling MA mod_status MA mod_substitute MA mod_unique_id MA mod_unixd MA mod_userdir MA mod_version MA mod_vhost_alias MA mod_watchdog # remove from 'most' A mod_cern_meta # remove from 'all' A mod_log_forensic A mod_mime_magic A mod_sed # add to 'most' ? A mod_usertrack mod_ldap # add to 'most' and 'all' (if ldap detected) mod_authnz_ldap # add to 'most' and 'all' (if ldap detected) mod_proxy # add to 'most' and 'all' mod_proxy_ajp # add to 'most' and 'all' mod_proxy_balancer # add to 'most' and 'all' mod_proxy_connect # add to 'most' and 'all' mod_proxy_fcgi # add to 'most' and 'all' mod_proxy_fdpass # add to 'all' mod_proxy_ftp # add to 'most' and 'all' mod_proxy_http # add to 'most' and 'all' mod_proxy_scgi # add to 'most' and 'all' mod_lbmethod_bybusyness # add to 'most' and 'all' mod_lbmethod_byrequests # add to 'most' and 'all' mod_lbmethod_bytraffic # add to 'most' and 'all' mod_lbmethod_heartbeat # add to 'all' mod_serf mod_slotmem_plain # add to 'all'? mod_ssl # add to 'most' and 'all' (if ssl detected) mod_suexec mod_bucketeer mod_case_filter mod_case_filter_in mod_cgi # add to 'most' and 'all' mod_charset_lite # add to 'most' and 'all' mod_dav_lock # add to 'all' ? mod_dialup # add to 'all' ? mod_echo mod_example_hooks mod_example_ipc mod_isapi # remove from 'reallyall' on unix mod_log_debug # add to 'all' mod_optional_fn_export mod_optional_fn_import mod_optional_hook_export mod_optional_hook_import
Re: reallyall vs. all vs. most
On Wednesday 06 July 2011, Jeff Trawick wrote: Troll Default set of loaded mods is more important Not enabling everything that is built would need some infrastructure to make it work on all supported platforms. I don't know how much effort that is, but unless someone implements it, there is IMHO no need to discuss the list of modules that would be loaded by default.
Re: reallyall vs. all vs. most
I aggree with Daniel and Gregg, that it may be better to have mod_log_debug at 'most'. And mod_lua better only at 'all', until it has matured more. On Wednesday 06 July 2011, William A. Rowe Jr. wrote: On 7/5/2011 4:21 PM, Stefan Fritsch wrote: MA mod_file_cache # remove from 'most' A noop if not explicitly enabled, you could probably leave it 'most'. Fine with me MA mod_ident # remove from 'most' and 'all' MA mod_imagemap# remove from 'most' and 'all' But present with 'reallyall'? That works. A mod_cern_meta # remove from 'all' But stuck on 'reallyall' I hope? Sure, nothing gets removed from reallyall. But IMO these three are _really_ obsolete, so no reason for 'all' or even 'most'. mod_proxy_ajp # add to 'most' and 'all' mod_proxy_fcgi # add to 'most' and 'all' mod_proxy_scgi # add to 'most' and 'all' Isn't 'all' enough? Pretty special-purpose, even tomcat is easier to manage from an http connector. Most people I know use AJP for tomcat, and fcgi is supposed to become the recommended method for php. Therefore I would definitely prefer 'most' for these two. Don't know about scgi. mod_ssl # add to 'most' and 'all' (if ssl detected) There is a long debate about this, and in 2011 it likely doesn't matter so much, but this was disabled explicitly due to the varied and ever changing government policies on munitions. It probably doesn't hurt to leave it at 'reallyall' when ssl is detected. The other argument is to install it for most and all, on the premise that if crypto is forbidden, openssl is not present in a usable form. Yes, that's my thought. If the openssl headers are in the default place, or there is a --with-ssl=/path on the command line, it's very unlikely that crypto is forbidden. mod_charset_lite# add to 'most' and 'all' All, sure, if APU_HAS_ICONV, but most? Pretty limited application. More than mod_file_cache, IMHO. And of course enable only if the deps are fullfilled. mod_echo All... noop if not configured. I would consider this more an example module. Or is this really used anywhere? mod_isapi # remove from 'reallyall' on unix No; leave it reallyall, it actually does work, and is probably as applicable as proxy_scgi. OK, didn't know that. I thought it was completely useless on unix.
Re: reallyall vs. all vs. most
On 05.07.2011 23:21, Stefan Fritsch wrote: On Tuesday 05 July 2011, Igor Galić wrote: even though it means that reallyall will yield different results on different systems That was the point of reallyall. Build everything that is possible with the installed dependencies. It wouldn't be very useful if you would need all kinds of weird third party libs to use it. Agreed. BTW, I think it would be more useful if all enabled more modules. Basically what reallyall does except for examples, hard core debugging, very experimental, and very obsolete stuff. Here is what gets built for most (M) and all (A) and what I would like to change. The choices are certainly subjective, but I think there should be many changes where we all agree. So please comment. Agree with all of it except for below comments. MA mod_file_cache # remove from 'most' No strong opinion about that. MA mod_lua Also suggest A as others did. MA mod_proxy_express # remove from 'most' (?) If Jim thinks it is ready for prime time, it would be useful in M. A mod_sed # add to 'most' ? Yes. mod_isapi # remove from 'reallyall' on unix Surprised by the comment of Bill, since the docs page only talks about Windows. Could be outdated. mod_log_debug # add to 'all' Suggest M. There's also mod_privileges, I think it is not in the list. I suggest: mod_privileges so reallyall for it? Regards, Rainer
Re: reallyall vs. all vs. most
On Wednesday 06 July 2011, Rainer Jung wrote: There's also mod_privileges, I think it is not in the list. I suggest: mod_privileges so reallyall for it? True, the modules that were not built on my system were missing in the list: mod_socache_dc mod_session_crypto mod_privileges They are currently all only built with reallyall. I would change mod_session_crypto to whatever mod_session is, dependencies permitting. This would mean 'most'. I don't mind about the other two, reallyall seems ok for them.
reallyall vs. all vs. most
On Tuesday 05 July 2011, Igor Galić wrote: even though it means that reallyall will yield different results on different systems That was the point of reallyall. Build everything that is possible with the installed dependencies. It wouldn't be very useful if you would need all kinds of weird third party libs to use it. BTW, I think it would be more useful if all enabled more modules. Basically what reallyall does except for examples, hard core debugging, very experimental, and very obsolete stuff. Here is what gets built for most (M) and all (A) and what I would like to change. The choices are certainly subjective, but I think there should be many changes where we all agree. So please comment. MA mod_access_compat MA mod_actions MA mod_alias MA mod_allowmethods MA mod_asis # remove from 'most' MA mod_auth_basic MA mod_auth_digest MA mod_auth_form MA mod_authn_anon MA mod_authn_core MA mod_authn_dbd MA mod_authn_dbm MA mod_authn_file MA mod_authn_socache MA mod_authz_core MA mod_authz_dbd MA mod_authz_dbm MA mod_authz_groupfile MA mod_authz_host MA mod_authz_owner MA mod_authz_user MA mod_autoindex MA mod_buffer MA mod_cache MA mod_cache_disk MA mod_cgid MA mod_data# remove from 'most' MA mod_dav MA mod_dav_fs MA mod_dbd MA mod_deflate MA mod_dir MA mod_dumpio MA mod_env MA mod_expires MA mod_ext_filter MA mod_file_cache # remove from 'most' MA mod_filter MA mod_headers MA mod_heartbeat # remove from 'most' MA mod_heartmonitor# remove from 'most' MA mod_ident # remove from 'most' and 'all' MA mod_imagemap# remove from 'most' and 'all' MA mod_include MA mod_info MA mod_log_config MA mod_logio MA mod_lua MA mod_mime MA mod_negotiation MA mod_proxy_express # remove from 'most' (?) MA mod_ratelimit MA mod_reflector # remove from 'most' MA mod_remoteip MA mod_reqtimeout MA mod_request MA mod_rewrite MA mod_session MA mod_session_cookie MA mod_session_dbd MA mod_setenvif MA mod_slotmem_shm MA mod_socache_dbm MA mod_socache_memcache MA mod_socache_shmcb MA mod_speling MA mod_status MA mod_substitute MA mod_unique_id MA mod_unixd MA mod_userdir MA mod_version MA mod_vhost_alias MA mod_watchdog# remove from 'most' A mod_cern_meta # remove from 'all' A mod_log_forensic A mod_mime_magic A mod_sed # add to 'most' ? A mod_usertrack mod_ldap# add to 'most' and 'all' (if ldap detected) mod_authnz_ldap # add to 'most' and 'all' (if ldap detected) mod_proxy # add to 'most' and 'all' mod_proxy_ajp # add to 'most' and 'all' mod_proxy_balancer # add to 'most' and 'all' mod_proxy_connect # add to 'most' and 'all' mod_proxy_fcgi # add to 'most' and 'all' mod_proxy_fdpass# add to 'all' mod_proxy_ftp # add to 'most' and 'all' mod_proxy_http # add to 'most' and 'all' mod_proxy_scgi # add to 'most' and 'all' mod_lbmethod_bybusyness # add to 'most' and 'all' mod_lbmethod_byrequests # add to 'most' and 'all' mod_lbmethod_bytraffic # add to 'most' and 'all' mod_lbmethod_heartbeat # add to 'all' mod_serf mod_slotmem_plain # add to 'all'? mod_ssl # add to 'most' and 'all' (if ssl detected) mod_suexec mod_bucketeer mod_case_filter mod_case_filter_in mod_cgi # add to 'most' and 'all' mod_charset_lite# add to 'most' and 'all' mod_dav_lock# add to 'all' ? mod_dialup # add to 'all' ? mod_echo mod_example_hooks mod_example_ipc mod_isapi # remove from 'reallyall' on unix mod_log_debug # add to 'all' mod_optional_fn_export mod_optional_fn_import mod_optional_hook_export mod_optional_hook_import
Re: reallyall vs. all vs. most
On 7/5/2011 4:21 PM, Stefan Fritsch wrote: Here is what gets built for most (M) and all (A) and what I would like to change. The choices are certainly subjective, but I think there should be many changes where we all agree. So please comment. +1 to all of your suggestions, though I wonder about mod_lua since it is also one of the mentioned experimental modules. I would also see a case for mod_log_debug to be in MOST. It's one of those modules that one wouldn't care too much about until it's needed. -- -- Daniel Ruggeri
Re: reallyall vs. all vs. most
On 7/5/2011 4:21 PM, Stefan Fritsch wrote: On Tuesday 05 July 2011, Igor Galić wrote: Here is what gets built for most (M) and all (A) and what I would like to change. The choices are certainly subjective, but I think there should be many changes where we all agree. So please comment. MA mod_file_cache # remove from 'most' A noop if not explicitly enabled, you could probably leave it 'most'. MA mod_ident # remove from 'most' and 'all' MA mod_imagemap# remove from 'most' and 'all' But present with 'reallyall'? That works. A mod_cern_meta # remove from 'all' But stuck on 'reallyall' I hope? A mod_sed # add to 'most' ? +1 mod_proxy_ajp # add to 'most' and 'all' mod_proxy_fcgi # add to 'most' and 'all' mod_proxy_scgi # add to 'most' and 'all' Isn't 'all' enough? Pretty special-purpose, even tomcat is easier to manage from an http connector. mod_ssl # add to 'most' and 'all' (if ssl detected) There is a long debate about this, and in 2011 it likely doesn't matter so much, but this was disabled explicitly due to the varied and ever changing government policies on munitions. It probably doesn't hurt to leave it at 'reallyall' when ssl is detected. The other argument is to install it for most and all, on the premise that if crypto is forbidden, openssl is not present in a usable form. mod_charset_lite# add to 'most' and 'all' All, sure, if APU_HAS_ICONV, but most? Pretty limited application. mod_echo All... noop if not configured. mod_isapi # remove from 'reallyall' on unix No; leave it reallyall, it actually does work, and is probably as applicable as proxy_scgi.
