On Wed, Aug 21, 2013 at 8:27 AM, Jim Jagielski <[email protected]> wrote:
> The 2.4 STATUS file has: > > * opinion on more complete DefaultRuntimeDir use in 2.4.x? > o If a module has a config directive for the run-time file that > treats the configured path as relative to server root, preserve > that behavior but change the location when not configured to > respect DefaultRuntimeDir. With these changes, users with no > per-runtime-file configuration directives can control > everything with DefaultRuntimeDir. > BUT: Existing users of DefaultRuntimeDir might get a short-term > scare > when some unconfigured run-time file starts respecting their > DefaultRuntimeDir directive after an upgrade. > +1: trawick, jim, rjung > rjung: applicable trunk revisions WITHOUT the compatibility tweaks > described above: > scoreboard r1369477 > core/pid file r1369808 > core/mutex r1370288 > mod_socache_XXX r1370225, r1407385 > mod_ldap r1371684 > mod_cache r1407381 > mod_slotmem_plain r1370763 > igalic: We have three votes, what's the status here? > Independently, backport any doc tweaks to 2.4 API migration page. > > To be honest, I also wonder what the status of this is... > I'd like to have the 1st 3 in 2.4, but am unsure what is > required, if anything, to make it acceptable. Is it just > the "preserve" line? > I think that we've already backported everything we can without risking a change in the meaning of someone's configuration. DefaultRuntimeDir can/should be used for new additions to 2.4 when appropriate, but these remaining ones are dangerous without some 2.4-specific mitigation. I'll try to look through this in the next day to see if there is some mitigation we can do to allow the feature without breaking any current 2.4 behavior. I fear that a "safe" implementation would require some explicit opt-in for these remaining features, and a config that did the opt-in could then move all the runtime files just by changing DefaultRuntimeDir. -- Born in Roswell... married an alien... http://emptyhammock.com/
