httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ralf S. Engelschall" <>
Subject Re: [PATCH] Configuration (1/4): Path Layout
Date Tue, 01 Dec 1998 18:28:22 GMT

In article <> you wrote:
> On Tue, 1 Dec 1998, Ralf S. Engelschall wrote:

>> Configuration (1/4): Path Layout [config-layout]
>> ------------------------------------------------
>> This patch tries to complete Randys work to change the default path layout in
>> APACI to the layout of --compat in a more generalized way.
>>  o there is no longer a _default_ path layout. This means
>>    the user _HAS_ to specifiy a path layout _explicitly_.  Only this way we
>>    can avoid confusion again because silently changing the layout to --compat
>>    would again cause confusion.
>>  o added a generic --with-layout=[FILE:]ID option. It has
>>    to be used to select the installation path layout.  ID here is a layout
>>    indentifier, currently "Apache" and "GNU" are pre-defined in the file
>>    config.layout.  Custom layouts are possible by using FILE:ID as the
>>    argument. Then the layout ID is taken from FILE. This makes the life of
>>    package vendors a little bit easier and avoids specifying thousends of
>>    options every time.

> I'm still a bit confused about where you get the idea that the
> apaci layout is any sort of "GNU" layout.  Do you have any reference
> that supports such an idea?  I'm not sure it is wise to call it
> a GNU layout in case someone wants to use a "real" GNU layout, which 
> is more logical AFAIK.

As I've already said two times in the past, the used paths are directly
derived from the GNU "standards" document. When these paths are not "GNU"
paths, what else? Hmmmm...  OTOH it's only _ONE_ single reference (inside the
"<Layout GNU>" string in config.layout), so it's not a great issue, IMHO. So,
for heaven's sake when you really dislike the string "GNU" rename it later to
"Fucking-RSE-Paths" when you want.... ;_)

                                       Ralf S. Engelschall

View raw message