Re: [Buildroot] [PATCH v3 07/16] package/pkg-generic.mk: detect files overwritten in TARGET_DIR and HOST_DIR

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

Thomas, Hervé, All,

On 2021-08-29 13:39 +0200, Thomas Petazzoni spake thusly:
> On Sun, 29 Aug 2021 00:47:40 +0200
> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:
> > However, what prompted me from applying for now, is that this new
> > detection is a hard error.
[--SNIP--]
> We had some discussion with Hervé back when he worked on this, and I
> disagreed with adding an option. When BR2_PER_PACKAGE_DIRECTORIES=y, a
> file overwrite must be a hard error, as the result of the build is
> incorrect if there is an overwrite. It's not the "latest" package that
> wins in an overwrite situation, like it does in a non-PPD case.

So, existing builds that succeed with PPD, and for which an overwrite
is not an issue even at runtime, will now be broken at build time.

After all, we _know_ there are users that already use PPD (for TLPB),
and those users have working systems, but I highly doubt these builds
have no file overwrite whatsoever...

> So I really think this must be a hard error for PPD builds, and just a
> warning for non-PPD builds.

For non-PPD, that code is not even used, because the macros are only
defined if BR2_PER_PACKAGE_DIRECTORIES=y; so for non-PPD, we will not
even get a warning.

> Yes, for PPD builds, it means users will get failures, but those
> failures are pointing to real problems.

I fully agree, but in practice, some of those overwrites may be totally
innocusous when running the system. Think the gnu info db: we 100% don't
care about it at runtime, but this is an overwrite (yes, we already
fixed that one, but it was in this cycle, so users of previous releases
who use PPD do have overwrites that they don't care about).

> So, my preference would be to merge as an unconditional check, and see
> how it goes.

OK, I am aligning with that position. Unless someone else beats me to
it, I'll resume work on this series later in the WE, or early next
week...

> Perhaps the situation will be so bad that we will have to
> make it conditional, but I would prefer to have it unconditional first
> and see the impact.

Note that my proposal would have unconditionally enabled it in the
autobuilders, so we would have noticed as well, so we can still do that
if we later decide to make the hard error conditional.

Finally, as a side note: there is still a case of file overwrite that we
do not detect, even with this series: if two packages that are not part
of the same dependency chain (i.e. they do not depend one on the other),
and they both install the same file, then the file-overwrite will only
happen when we eventually assemble the global target/ and host/ from the
individual PPD target/ and host/ and we still have to add a detection
for that case (which is not a pre-requisite before we apply the current
series, of course).

Regards,
Yann E. MORIN.

> Best regards,
> 
> Thomas
> -- 
> Thomas Petazzoni, co-owner and CEO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-- 
.-----------------.--------------------.------------------.--------------------.
|  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.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot