OpenWireless icon indicating copy to clipboard operation
OpenWireless copied to clipboard

Package for easier integration into OpenWrt

Open RussellSenior opened this issue 10 years ago • 6 comments

It seems to me, a project such as this ought to be organized in such a way as to exploit and assist the ongoing effort developing OpenWrt, and ought to use the established mechanisms in OpenWrt for extension, such as package feeds, meta packages, etc. It is not necessary, and seems counter productive, to fork as hard as you have. It makes reviewing the differences more difficult, it makes upstreaming your improvements more difficult, etc.

RussellSenior avatar Jul 21 '14 21:07 RussellSenior

/signed 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.

MaStr avatar Jul 23 '14 18:07 MaStr

This is great feedback, thanks. We'd definitely like to use existing mechanisms to make upstreaming easier. Is that something you'd be able to provide assistance or guidance on? Should we provide our changes as an opkg, or something else?

jsha avatar Jul 23 '14 19:07 jsha

Hi jsha, you can use ImageBuilder in two ways:

  1. Copy over a Filesystem
  2. 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.

see some raw magic here: https://github.com/PirateBox-Dev/openwrt-image-build https://github.com/PirateBox-Dev/openwrt-image-build/tree/AA-with-installer

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.

Matthias

edit: I forgot one thing: Using ImageBuilder saves trees, because less compiling to create images. ;)

MaStr avatar Jul 23 '14 20:07 MaStr

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.

RussellSenior avatar Jul 24 '14 04:07 RussellSenior

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.

RussellSenior avatar Jul 24 '14 04:07 RussellSenior

Oh, also look into OpenWrt's scripts/diffconfig.sh for creating minimal .config's, which you can subsequently expand/fully-populate with "make defconfig".

RussellSenior avatar Jul 24 '14 04:07 RussellSenior