[ITP] Apache 2.0

[Max Bowsher]

Corinna Vinschen wrote:
> On Jun 20 12:20, Max Bowsher wrote:
>> Corinna Vinschen wrote:
>>> On Jun 20 01:57, Max Bowsher wrote:
>>>> There doesn't seem to be any particular consensus between Linux distros
>>>> on whether the package should be called "apache2" or "httpd".
>>>> I have chosen to follow the naming of the official tarball, and call it
>>>> "httpd". (Red Hat/Fedora does the same, FWIW)
>>> 
>>> I like "apache2" better, FWIW.
>> 
>> The assumption that package name == tarball stem name is somewhat implied
>> by the generic-build-script system. It wouldn't be impossible to work
>> around, but it would be a bit weird.
>> 
>> What should the filenames be?
> 
> Oh, I don't care.  I just expressed my opinion.  If you're more happy
> with httpd, it's your choice.

After pondering it a bit, I decided that I was just being lazy, and I like apache2 better too.

>>> - Why is the library not in /usr/bin as every other shared lib which is
>>> load-time linked?
>> 
>> It seemed neater, and eliminating potential problems, to put it alongside
>> the only executable that needed it, so that it would be found independent
>> of PATH.
>> 
>>> - Why is it called .so?  I have no problems with run-time linked modules
>>> called .so, we already have a couple of these, but I'm reluctant to call
>>> load-time linked libs .so. Did you test it on 9x?
>> 
>> No, I said goodbye to my last 9x machine a *loooong* time ago.
>> 
>>> I know for sure that
>>> you can call executables "foo" instead of "foo.exe" on NT, but the same
>>> doesn't work on 9x.  What about load-time linked DLLs?
>>> 
>>> - Why are the *.dlla. and *.la files in /usr/sbin?  They belong under
>>> /usr/lib, don't they?
>> 
>> The .so naming was specifically to cause this, (it's the only way to stop
>> libtool from putting the dll in ../bin). The reason was to keep all of the
>> files related to this implementation detail in a single directory.
> 
> I understand what you are up to and the idea is neat.  But you know that
> cygwin1.dll is in /bin anyway.  If the system can't find cygwin1.dll, it's
> pretty much irrelevant if it finds cyghttpd2core.{so,dll}, isn't it?
> I think it might be better to keep it in /bin and especially keep the dll
> suffix to avoid any potential problem with 9x.  You have been warned ;-)

True.

Fixed packages coming up soon.

Max.