> 2. Looking at perl and PHP, the pattern is: > > /usr/<component_name><major_version>/<version>/... > > So there is for example > > /usr/perl5/5.8.4/[bin|lib|...] > > Similarly, PHP (2007/168) will deliver into: > > /usr/php5/5.2.3/[bin|lib|...] > > Applying this to the current apache 2.x work, results in > > /usr/apache2/2.2.4/[bin|lib|...]
> #2 has the argument going for it that it follows previously approved > practice (perl, PHP). The pesky detail is that there is already Apache > 2.0 in /usr/apache2/. I agree that it's a pesky detail but for Indiana, it seems inflicting this sort of reorganization may be worth the trouble *if* we believe having multiple versions of a major release of Apache in play are worth it. As I mentioned in an earlier email, my inclination based on what I know about Apache usage is that having a single major version would be acceptable but I certainly am open to hearing from others (still need to catch up on comments from Matt and Joe on this, I think). One argument for creating a hierarchy to support multiple versions is that it would allow transitions to take place using containers on the same system. One could have a production container running Apache 2.2.4 and a second container running 2.3. That said, in talking with customers what I've heard is that there is rarely this mixing of production and either dev or test environments on the same physical system/domain. Leaving aside the /usr hierarchy for the moment (which contains no user-editable files and so "moving" the older hierarchy to a new one may be fairly easy), what about /etc/apache2 and /var/apache2? Is there a need to create separate versions of this on the same system or is the configuration language compatible across different *minor* versions? dsc
