Custom Sing-box: Updating OpenWrt Feeds

Ever found yourself diving deep into OpenWrt configurations, wanting to leverage the power of sing-box but hitting a wall because the default version in the feeds just doesn't cut it? You're not alone! Many of us are looking for ways to integrate more advanced or customized versions of sing-box, especially those that come with handy features like provider support, which are crucial for dynamic configuration management. This guide is all about navigating the process of replacing the default sing-box in your OpenWrt feeds with a fork of your choice, ensuring you get the most out of your network setup. We'll walk through the common pitfalls, like the dependency warnings you might encounter, and provide a clear path forward. So, whether you're a seasoned OpenWrt enthusiast or just getting started with custom firmwares, this article aims to empower you with the knowledge to successfully update your sing-box package.

Understanding the OpenWrt Build System and Feeds

Before we jump into the nitty-gritty of updating sing-box, it's essential to have a grasp of how OpenWrt's build system and package feeds work. OpenWrt uses a modular build system that allows users to select and compile specific packages for their router. The 'feeds' are essentially repositories that contain the source code and build instructions for these packages. When you run commands like scripts/feeds update -a and scripts/feeds install -a, you're telling your OpenWrt build environment to fetch the latest package information from these feeds and make them available for installation. The packages.sh script you might have tried to edit is part of this process, allowing you to specify custom package sources. However, OpenWrt's dependency management is quite strict. If a package relies on another package (or a specific version of it) that isn't found or correctly defined in your build environment, you'll run into errors, like the WARNING: Makefile 'package/luci/applications/luci-app-homeproxy/Makefile' has a dependency on 'sing-box', which does not exist you encountered. This warning is a clear indicator that the system can't find a package named sing-box that meets the requirements of luci-app-homeproxy.

To effectively replace the default sing-box, you need to ensure your custom fork is not only accessible but also correctly registered within the build system so that other packages depending on it can find it. This often involves more than just pointing to a new Git repository. You might need to adjust the package's Makefile (Makefile within the package's directory) to correctly define its name, version, dependencies, and build options. Furthermore, if you're trying to replace a package that's already part of the core feeds, you need to make sure your custom version takes precedence or that the original is properly overridden. The goal is to seamlessly integrate your chosen sing-box fork, making it indistinguishable to the build system from a standard package, thus resolving dependency issues and allowing the compilation to complete successfully. This process requires careful attention to detail in how you structure your custom package additions and how you modify the relevant Makefiles.

Troubleshooting Dependency Warnings

The specific warning you received – WARNING: Makefile 'package/luci/applications/luci-app-homeproxy/Makefile' has a dependency on 'sing-box', which does not exist – is a common hurdle when trying to introduce custom packages. It means that luci-app-homeproxy, which is a graphical interface for managing proxy settings, relies on a package named sing-box being available in your build environment. When you tried to add your custom sing-box fork using `UPDATE_PACKAGE