Hi all,

i'm quiet busy theese days and would like to share my last efforts in providing another tool to help build and provide packages in a more convenient way.

The idea is to provide a tool that is able to build packages locally (almost) anywhere from (almost) nothing, just knowing a source name.

I made a little HOWTO/README available, just take a look, i'm waiting for your feedback...

--
Nico

sounds great and I am looking for such a tool. Just  wonder if it is possible to make the "download" more generic like copy from some local directory(be it tz2 or already expanded).

For example, I am looking for a dyndns update client which the linksys source tree already has one but the current openwrt build script doesn't use. While it is still possible to download from the upstream source, this linksys version may have some of the problem fixed(if any) and it may be more desirable to use it.

It could be possible to copy the directory from the linksys source tree, but the component usually need to be compiled in place (from what I've seen, they reference other files in their Makefiles).

From what I've done for some OpenWRT components (like kernel modules), I would provide a "fake" source tarball that just contain the ipkg stuff (rules and control files). The "rules" could build the source in place and then install in the target directory that the script would package.

I guess you're talking about "ipupdate" from the linksys source. I could provide a package demonstrating the issue if you really need it.

--
Nico

yes, ipupdate is what I am looking at. It seems to be a more complete dynamic DNS client.

I have some reservations with depending on download locations for package building. Just consider the problems people have with changing locations in the current OpenWRT buildroot already. Aside from that, it's not a bad idea, except maybe for the implementation.

How about this:

- Create a build directory, cd into it
- Download a top level Makefile from a location
- Set an environment variable to the OpenWRT buildroot
- type 'make'

The Makefile only downloads the original source, it downloads the patch to create an ipkg directory (with everything in it), and it kicks off ipkg-buildpackage -c. Done. Together with what I already have, constructing such a (skeleton) toplevel Makefile only would take about 5 minutes work.

The top level makefile should contain everything it needs to download, patch and build the package. No need for an unsupported, non standard extension of the ipkg control file, and there's no need for yet another script to parse the Control file to do stuff. Nor is there a need for yet another packaging directory.

Polarwolf,

the approach you propose (and use I guess) is fine, but leave some problems unaddressed:

1) each "rules" file will have to define a bunch of variables used for cross-compilation, cflags, etc...

2) ipkg-buildpackage doesn't know how to build multiple packages for a single source

3) dependencies are not handled

Theese problems could be handled:

1) if you provide a OPENWRT_BUILDROOT environment variable, we could source a "make" file containing all variables used for package building

2) ipkg-buildpackage could be patched to let the "rules" file build its packages if it knows how. We could add a "binary" target to the "rules" file and let ipkg-buildpackage test for it (ipkg/rules -n binary), if it gets an error then the "rules" file is ignorant and ipkg-buildpackage can continue the usual way

3) dependencies are complex, for sure, but should be addressed

Let me know what you (and others) think, I'd really like to help...

--
Nico

Packaging software is hard. Ask the debian guys :-)

Your point #1 is easily solved, as you yourself already wrote. #2 is a bit trickier as that is really a limitation in the ipkg utils. It can be added into the toolchain, sure, and I for one would really appreciate it. However, I don't really have the time to look into it too deeply. #3 is indeed a complex issue, and I don't think it's one which can be solved easily. It's not too hard to hack some halfassed solution with a script or a makefile (simply chain a truckload of package builds together), but it'll never be something which will work well.

I think it would be best to first get a good idea which problem you want to solve. Is it to make it easy for people to reproduce packages you made? Is it to make your life as software package easier when packaging new stuff? Or for maintaining your existing set of packages easier? Is it to make it easier for people to package their own software?

I'm a bit confused as to what goal it is you want to reach. I suspect you want to create an easy way for people to build a package, including its dependencies from scratch with only buildroot available.

just try it to build ez-ipupdate and works fine(of course as you have that in your repository). Just a minor note, you use "sed -i" which is not a valid opt on my machine which happens to be debian woody. I need to update sed for it. May be a note in the readme ?

BTW, can this tools used to build kernel modules outside the vanilla kernel, such as alsa ? I just bought a WL500G which has a USB port and I want to test the possibility of using a bluetooth headset as the audio device on it. Unfortunately, there is no oss driver for bluetooth and only alsa.

There may be other kernel modules as well like webcam etc.