From mboxrd@z Thu Jan 1 00:00:00 1970 From: Yann E. MORIN Date: Sat, 11 Apr 2020 19:41:57 +0200 Subject: [Buildroot] [PATCH 5/8] core/show-info: report whether a package is overriden In-Reply-To: <20200411161439.7f7c784f@windsurf.home> References: <524b53bb81ecd33c55b242d239bee93f57c6c98b.1586592741.git.yann.morin.1998@free.fr> <20200411103602.75d8b9f2@windsurf.home> <20200411094436.GK29898@scaer> <20200411144248.49090e99@windsurf.home> <20200411132258.GM29898@scaer> <20200411161439.7f7c784f@windsurf.home> Message-ID: <20200411174157.GN29898@scaer> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: buildroot@busybox.net Thomas, All, On 2020-04-11 16:14 +0200, Thomas Petazzoni spake thusly: > On Sat, 11 Apr 2020 15:22:58 +0200 > "Yann E. MORIN" wrote: > > > Well, from an internal implementation point of view, SITE_METHOD = > > > local and OVERRIDE_SRCDIR are just exactly the same thing. > > But that is an implementation detail, indeed. > > In fact, we should have had local support without override support. And > > then we should have grafted override suport on top of the local one, > > while the code as it is makes local re-use the override code... > I am not sure what that would bring, and how that would make things > better/clearer. Ultimately, what happens for both overridden packages > and local packages is that they are rsynced. I'd still like to be able to tell the two apart, but that is eventually orthogonal to the current topic. > > > Perhaps you could use: > > > "rsynced": $(if $($(1)_OVERRIDE_SRCDIR),true,false), > > Fact is, that still does not reflect what I want to expose. An overriden > > package is de-facto not reproducible, while a local package may. > I don't understand why a local package is more reproducible than an > overridden package. In both cases, Buildroot cannot guarantee the > reproducibility. If the package is in the same sourec tree as Buildroot (or a git-submodule or something like that), then it is reproducible (as it is in VCS and de-facto referenced by a specific commit that brings both Buildroot and the package sources. That's why a Isaid that a local packge "may" be reproducible. > > But I don't care enough to argue further. "resynced" gets the same value > > as "overriden", and since we can;t get the semantic of "overriden", it > > is as good as it is. > I don't follow your reasoning here. I am fine with having the boolean > this patch proposes to add, I was just suggesting another term than > "overridden", as that was not really covering the case of local > packages. Yes, you are right here; I got side-tracked. For the stampfiles, we don't need to discrimninate between local or overriden: we just need to know it is rsynced (or downlaoded-extracted-patched). > > > I think this particular patch is OK, even though admittedly the > > > external tool could just watch for the correct stamp files to show up: > > > if .stamp_downloaded shows up, we're downloading it normally, if > > > .stamp_rsynced shows up, we have a local or overridden package. > > > In the design of the tool, it would be good to make sure that top-level > > > parallel build is taken into account. > > Which is exactly what I am trying to achieve here: provide all the info > > about the internal details, so that the tool does not have to guess. > And I'm not sure it's a worthwhile goal. I think the tool should just > have the knowledge of what possible stamp files exist, and what are the > possible sequences of stamp file creation. OK. I'll drop from my series the parts related to that... Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------'