From patchwork Thu Feb 20 17:01:30 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Yann E. MORIN" X-Patchwork-Id: 322264 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from whitealder.osuosl.org (whitealder.osuosl.org [140.211.166.138]) by ozlabs.org (Postfix) with ESMTP id 0E2BF2C009E for ; Fri, 21 Feb 2014 04:01:43 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 081AB8BF2F; Thu, 20 Feb 2014 17:01:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nO7KTYMYkLq4; Thu, 20 Feb 2014 17:01:39 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by whitealder.osuosl.org (Postfix) with ESMTP id 32DB68B888; Thu, 20 Feb 2014 17:01:39 +0000 (UTC) X-Original-To: buildroot@lists.busybox.net Delivered-To: buildroot@osuosl.org Received: from hemlock.osuosl.org (hemlock.osuosl.org [140.211.166.133]) by ash.osuosl.org (Postfix) with ESMTP id 434721C1045 for ; Thu, 20 Feb 2014 17:01:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 4560788B70 for ; Thu, 20 Feb 2014 17:01:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9DYld9AUGsUv for ; Thu, 20 Feb 2014 17:01:36 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) by hemlock.osuosl.org (Postfix) with ESMTPS id 1813487F06 for ; Thu, 20 Feb 2014 17:01:35 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id l18so765417wgh.0 for ; Thu, 20 Feb 2014 09:01:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:date:message-id:in-reply-to:references; bh=1GreC2DkFk9fjyxC87a75tvbTfBI4AZnExubyR7k6Ts=; b=Lm/FBvKT80Cthz/tww9GzUfPqzl2ZyIM4mD/ATS5Dl1OwjqdZ+44ore+suQAbT/zev Me4Rorm42kCNywsY7IxaISlyI19Bmm19IBC32XjXeCGBuboe+Y05fLzK/PfKa8EZgcyz AM91pDhf6uzEkPCEjRlqXJGO+Xtom5eSTVEN/APCmJlSvyp3K6yLtjmul3ZBoE271j/S 6KEEZKFi+hxE2Aizb1U2pph9sit2zBZaho19rDAVQ7CuPALW7LBBB2beApyPMna3pUwv UVlmNFmE2uANvQO5OwaePPXkO/tc04/TJv1a7DVXItcnO2ImZceeiHA0d52zQzXNJFya Kklg== X-Received: by 10.194.77.7 with SMTP id o7mr3032610wjw.35.1392915693469; Thu, 20 Feb 2014 09:01:33 -0800 (PST) Received: from gourin.bzh.lan (ks3095497.kimsufi.com. [94.23.60.27]) by mx.google.com with ESMTPSA id ee5sm27706wib.8.2014.02.20.09.01.31 for (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Feb 2014 09:01:32 -0800 (PST) From: "Yann E. MORIN" To: buildroot@buildroot.org Date: Thu, 20 Feb 2014 18:01:30 +0100 Message-Id: X-Mailer: git-send-email 1.8.1.2 In-Reply-To: References: Cc: Thomas Petazzoni , Peter Korsgaard , "Yann E. MORIN" Subject: [Buildroot] [PATCH 1/1] manual/faq: add section about why no binary packages X-BeenThere: buildroot@busybox.net X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion and development of buildroot List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: buildroot-bounces@busybox.net Sender: buildroot-bounces@busybox.net From: "Yann E. MORIN" It comes up every now and then on the list, so better be prepared to point at the manual, rather than rehash the same every time. Most of the chapter is a copy-paste of the report from the Buildroot Developpers Day in Pragues, 2011-10-28: http://lists.busybox.net/pipermail/buildroot/2011-November/047229.html We consider the opinions expressed in that report to be still valid now, two years later. Signed-off-by: "Yann E. MORIN" Cc: Samuel Martin Cc: Peter Korsgaard Cc: Arnout Vandecappelle Cc: Thomas Petazzoni Cc: Thomas De Schampheleire Cc: Baruch Siach Cc: Danomi Manchego --- docs/manual/faq-troubleshooting.txt | 100 ++++++++++++++++++++++++++++++++++++ 1 file changed, 100 insertions(+) diff --git a/docs/manual/faq-troubleshooting.txt b/docs/manual/faq-troubleshooting.txt index 4e0612b..4026e18 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.