On Sat, Aug 24, 2013 at 5:50 PM, Jeff Trawick <[email protected]> wrote:
> On Wed, Aug 21, 2013 at 9:05 AM, Jeff Trawick <[email protected]> wrote: > >> 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. >> > > Wow, days go by quick if you're learning cmake and shaking the rust off > your Windows-ability... > > Here's the best I could come up with: > > In 2.4.x branch, DefaultRuntimeDir could take an optional additional > parameter, "full", which means that it applies even to the half-dozen items > that it didn't apply to in 2.4.0-2.4.6. Those half-dozen modules in 2.4.x > that didn't consult ap_runtime_dir_relative() before would check the global > "full" setting to know whether to start using it like in trunk. If "full" > isn't specified, those modules would use the same logic they use in > 2.4.0-2.4.6. > I guess it could instead be a ./configure/cmake option, which distributors might want to enable if they haven't yet distributed a 2.4[-based] server. That would be cleaner implementation-wise but wouldn't be an obvious choice for current 2.4 users. > Configure "DefaultRuntimeDir non-default-value full" but don't separately > configure those half-dozen items, and suddenly the scoreboard file and pid > and (usually) some less interesting objects move to the "right" place. > > -- > Born in Roswell... married an alien... > http://emptyhammock.com/ > -- Born in Roswell... married an alien... http://emptyhammock.com/
