You can even produce kernel-module compatible firmwares using ImageBuilder and custom repository-feeds. (What the hell is ImageBuilder? http://wiki.openwrt.org/doc/howto/obtain.firmware.generate ; A Elegant way to refit the stock binary firmwares with other software then install without recompiling everything)
But anyway, Go forward with your project. It seems promising.
you can use ImageBuilder in two ways:
Copy over a Filesystem install aditional packages including its dependencies. On the PirateBox/LibraryBox Project, we use this to create custom images. These custom images are shipped with additional entries in opkg.conf, where opkg can get additional software-packages (in our case plattform independend script .ipk files). 95% of the scripts, we ship, are made in the OpenWRT Makefile format and 100% compatible with the Build-environment. They can easily added to the feeds using an additional feeds.conf entry. (You don't need to have the 100% compatibility, you only have to make sure some rules are fullfilled that opkg can pull dependencies...)
I created a github repository with the latest stable and dev. status of the packages that can be hooked into the feeds.conf easily https://github.com/PirateBox-Dev/openwrt-piratebox-feed
After creating the packages, you get a working package repository. I strip it down to our own packages, that it is additional to the normal packages shipped by openwrt. I use those repositories as a package source online, or locally for development.
That looks like that: http://stable.openwrt.piratebox.de/all/packages/ Dependencies to normal OpenWRT Packages are pulled as regular.
Because PirateBox/LibraryBox uses the USB Stick as an installtion destination for supporting devices with much less firmware space, we have to have 2 step installation. First the Firmware including the pacakges which need to be on the firmware itself. The second installation is done by a tiny script during bootup that installs the needed packages to the USB stick (Like python). To prepare the package for the 2nd step & to prepare all the LibraryBox/PirateBox supported auto-install devices, I created a Makefile that do ALOT of the stuff with the imagebuilder automatically.
yes, I know. I'm absolutely NO make-guru.. I'm learning that all by DIY.. but it is quite handy. BTW: You can even REMOVE preinstalled packages, like I did with PPP. .. the imagebuilder itself gives you alot information about the install Profile.
Ok, that's some about the imagebuilder.
Some more confusing things about the opkg thing. As I mentioned above, there is no need to run through the openwrt-Buildchain all the time to repackage your package. It makes some things easier like finding dependency issues... but it makes it complex as well. If you have the need to have binaries compiled, you won't overcome this.
But, if you only deploys scripts, you can do small "fake" pacakges, like PirateBox had before. One example to create these fake packages, you can find here: https://github.com/MaStr/mkPirateBox-Mesh You need a debian-binary file, and then the different installation parts with the most important part: the "control" member containing dependencies, package name and so on. So you can create packages very quickly. After you collected all the .ipk files together in one folder, you can quickly generate the Package-index file using scripts/ipkg-make-index.sh out of the openwrt repository.
And one big big big request: Don't simply overwrite all the config stuff. In my opinion that is poison for device compatibility. Use UCI and some clever scripts for enhancing or changing stuff
I think, that is enough. I know that PirateBox is maybe not the reference-Project, but I tried to stay as close as possible to stock OpeWRT.
Yes, generally I would recommend that any new software be packaged and added to an openwireless feed. Any existing packages you feel require modification should probably be copied to the openwireless feed and patched there (so the differences between upstream can be more easily discerned, maybe named with an ow- prefix (for openwireless), or similar to distinguish. Any custom configuration that doesn't bind closely to a package could be bundled with a meta package that depends on the packages you require. Also, look at the uci-defaults infrastructure for applying configuration changes.
To elaborate slightly, uci-defaults holds scripts that run at boot time. If/when they exit with status 0, they are deleted and not run again. They can do anything a shell can do, but typically are used to manipulate configurations using the uci interface.
Oh, also look into OpenWrt's scripts/diffconfig.sh for creating minimal .config's, which you can subsequently expand/fully-populate with "make defconfig".
edit: I forgot one thing: Using ImageBuilder saves trees, because less compiling to create images. ;)