diff --git a/docs/manual/faq-troubleshooting.txt b/docs/manual/faq-troubleshooting.txt index 4e0612b8d7..4026e18ebd 100644 --- a/docs/manual/faq-troubleshooting.txt +++ b/docs/manual/faq-troubleshooting.txt @@ -111,3 +111,103 @@ directory as the new root, will most likely fail. If you want to run the target filesystem inside a chroot, or as an NFS root, then use the tarball image generated in +images/+ and extract it as root. + +[[faq-no-binary-packages]] +Why doesn't Buildroot generate binary packages (.deb, .ipkg...)? +---------------------------------------------------------------- + +One feature that is often discussed on the Buildroot list is the +the general topic of "package management". To summarize, the idea +would be to add some tracking of which Buildroot package installs +what files, with the goals of: + + * being able to remove files installed by a package when this package + gets unselected from the menuconfig; + + * being able to generate binary packages (ipk or other format) that + can be installed on the target without re-generating a new root + filesystem image. + +In general, most people think it is easy to do: just track which package +installed what and remove it when the package is unselected. However, it +is much more complicated than that: + + * It is not only about the +target/+ directory, but also the sysroot in + +host/usr//sysroot+ and the +host/+ directory itself. All files + installed in those directories by various packages must be tracked. + + * When a package is unselected from the configuration, it is not + sufficient to remove just the files it installed. One must also + remove all its reverse dependencies (i.e packages relying on it) + and rebuild all those packages. For example, package A depends + optionally on the OpenSSL library. Both are selected, and Buildroot + is built. Package A is built with crypto support using OpenSSL. + Later on, OpenSSL gets unselected from the configuration, but + package A remains (since OpenSSL is an optional dependency, this + is possible.) If only OpenSSL files are removed, then the files + installed by package A are broken: they use a library that is no + longer present on the target. Although this is technically doable, + it adds a lot of complexity to Buildroot, which goes against the + simplicity we try to stick to. + + * In addition to the previous problem, there is the case where the + optional dependency is not even known to Buildroot. For example, + package A in version 1.0 never used OpenSSL, but in version 2.0 it + automatically uses OpenSSL if available. If the Buildroot .mk file + hasn't been updated to take this into account, then package A will + not be part of the reverse dependencies of OpenSSL and will not be + removed and rebuilt when OpenSSL is removed. For sure, the .mk file + of package A should be fixed to mention this optional dependency, + but in the mean time, you can have non-reproducible behaviors. + + * The request is to also allow changes in the menuconfig to be + applied on the output directory without having to rebuild + everything from scratch. However, this is very difficult to achieve + in a reliable way: what happens when the suboptions of a package + are changed (we would have to detect this, and rebuild the package + from scratch and potentially all its reverse dependencies), what + happens if toolchain options are changed, etc. At the moment, what + Buildroot does is clear and simple so its behaviour is very + reliable and it is easy to support users. If configuration changes + done in menuconfig are applied after the next make, then it has to + work correctly and properly in all situations, and not have some + bizarre corner cases. The risk is to get bug reports like "I have + enabled package A, B and C, then ran make, then disabled package + C and enabled package D and ran make, then re-enabled package C + and enabled package E and then there is a build failure". Or worse + "I did some configuration, then built, then did some changes, + built, some more changes, built, some more changes, built, and now + it fails, but I don't remember all the changes I did and in which + order". This will be impossible to support. + +For all these reasons, the conclusion is that adding tracking of +installed files to remove them when the package is unselected, or to +generate a repository of binary packages, is something that is very +hard to achieve reliably and will add a lot of complexity. + +On this matter, the Buildroot developers make this position statement: + + * Buildroot strives to make it easy to generate a root filesystem (hence + the name, by the way.) That is what we want to make Buildroot good at: + building root filesystems. + + * Buildroot is not meant to be a distribution (or rather, a distribution + generator.) It is the opinion of most Buildroot developers that this + is not a goal we should pursue. We believe that there are other tools + better suited to generate a distro than Buildroot is. For example, + http://openembedded.org/[Open Embedded], or https://openwrt.org/[openWRT], + are such tools. + + * We prefer to push Buildroot in a direction that makes it easy (or even + easier) to generate complete root filesystems. This is what makes + Buildroot stands out in the crowd (among other things, of course!) + + * We believe that for most embedded Linux systems, binary packages are + not necessary, and potentially harmful. When binary packages are + used, it means that the system can be partially upgraded, which + creates an enormous number of possible combinations of package + versions that should be tested before doing the upgrade on the + embedded device. On the other hand, by doing complete system + upgrades by upgrading the entire root filesystem image at once, + the image deployed to the embedded system is guaranteed to really + be the one that has been tested and validated.