Joe McCabe wrote:
>
> > The engineering discussion here is whether the layout should permit
> > that, keeping in mind complexity isn't free.
>
> And strictly from that point of view I think the file layout should
> accommodate multiple versions installed at the same time.
Assuming it did, how might it be implemented?
- If 2.2 (current plan 2.2.4) does not overwrite the 2.0 previously
shipped, where would it go?
- By extension, if at some future date 2.4 is integrated and it does
not overwrite previous 2.x versions, where would it go?
I'll summarize previous discussions for context:
First, what's already there in S10:
/usr/apache - containing Apache 1.*
/usr/apache/bin, /usr/apache/man, and so forth.
/usr/apache2 - containing Apache 2.0 [.58]
/usr/apache2/bin, /usr/apache2/lib, and so forth.
1. During 2007/169 discussion, one possibility that was thrown around
was to have a top-level directory for 2.2: /usr/apache2.2/...
So for a hypotetical 2.4, presumably there'd be /usr/apache2.4/...
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|...]
IMO, #1 is not right. Introduces a lot of version clutter at the top
/usr level for a single component. Let's not.
#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/.
--
Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
