* this fixes the wrong recipe names introduced by myself in #d525fee
* adjust patch names to match corresponding recipes
* additionally: create 'additional-files' folders as hint to some
ports that do not have a proper recipe yet
WIP on taglib recipes, Note that taglib-1.8 won't build with gcc2,
Thus for a gcc2 built armyknife we may need a taglib-1.7.2 library.
Fix filename for ed-1.7, still may need more work, not fully tested
yes but it is getting further than previous version.
* Remove the other non-recipes/patches.
* We use the bz2 source archive. The xz URL is included as a comment.
Would be nice, if both could be specified and haikuporter would pick
one it has an unarchiving tool for.
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.
be declared properly, now
* improve formatting of recipe files for better readability and better
compatibility with showing diffs (when moving specification lines)
* add/improve DESCRIPTION where it was just a copy of SUMMARY
* add missing prerequisites cmd:gcc, cmd:make and cmd:sed
* switch build stage to use autoreconf instead of autoconf, as was
hinted by a message during the build before, however that doesn't
seem to help much with respect to getting rid of warning messages
* Also declare a resolvable named like the package, even if
similarly named cmd:* resolvable is declared.
* Add cmd: namespace to resolvables in [BUILD_[PRE]]REQUIRES
where appropriate. For some reason I thought that didn't
work (resulting in an error building the package), but
apparently I was mistaken.
* A few smaller fixes in [BUILD_[PRE]]REQUIRES.
