[Buildroot] [PATCH 5/8] core/show-info: report whether a package is overriden

[Yann E. MORIN <yann.morin.1998@free.fr>]

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" <yann.morin.1998@free.fr> 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.  |
'------------------------------^-------^------------------^--------------------'