* Correct version of provided lib:libsqlite3 -- it has it's own
versioning.
* Drop provided lib:libsqlite.
* Move the development library stuff to develop/lib.
Due to man needing a config file and our package manager/daemon not
supporting any settings file handling one has to manually copy the
man.conf from the package to the respective settings directory to
make things work.
Mostly fixes for using the correct paths for package management, like
not using absolute paths for the tools that man invokes, and using
the correct man search paths.
Displayed man pages contain uninterpreted escape sequences. It works
correctly when adding the '-r' option to DEFAULTLESSOPT (or piping to
"less -irs"), but the comment for this variable explicitly notes that
having to do that hints toward a broken setup. So I didn't do that and
we'll see later whether the current Haiku does better.
* liberate requirement on automake from 1.11 to generic, as there's hope
that any automake equal or newer than 1.11 will do
* add patch for removing dependency to help2man which is being invoked
to regenerate the manpages, which won't work and has become an error
with automake-1.13
* move patches for 2.4 into a corresponding subfolder
* explictly list patches
* Updated to version 2.0 of vendor code.
* Reliability improvements in controlling the underlying devices.
* Implement leaving networks.
* Better timeout handling.
* Usability enhancements like cancel on escape, ok button being the
default and the password field having focus on start.
* Storing of the password using BKeyStore.
I tried a bit, but there's no easy way of building with gcc 2, as the
code makes heavy use of C99 features. Should we really need to build
it with gcc 2, we should at least deal with the local variable
declarations not at the beginning of a block in an automated fashion.
problem is that apr-util won't build yet, due to it relying on the sources of apr being around. We need support for source packages to solve that, so that will be the next step.
* strip debug info from all binaries
* based on architecture, decide whether or not to link the tools into
the default path
* use relative symlinks instead of absolute ones, as the latter won't work
when building gcc with itself (in which case the .self-symlink in the
/packages folder will point to the packaging path, where no binaries
exist yet)
