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

Hi all,

On 29.08.21 17:01, Arnout Vandecappelle wrote:

On 29/08/2021 13:39, Thomas Petazzoni wrote:

quoted

Hello Yann,

First of all, thanks a lot for reviewing and merging bits of this
patch series, I'm glad to see we're making progress with the TLP
stuff.

On Sun, 29 Aug 2021 00:47:40 +0200 "Yann E. MORIN"
[off-list ref] wrote:

quoted

However, what prompted me from applying for now, is that this
new detection is a hard error.

Previously, check-uniq-files was just emitting warnings, but
would not prevent the build from failing. Now, with this patch,
even an innocuous overwrite (e.g. because a post-build script
deletes the file, or the content of the file really does not
matter at runtime), the build will fail.

I.e. configurations that are currently working with PPD, despite
the overwrite, will suddenly no longer build.

OTOH, if we do not make that a hard-error, we will never detect
most issues, because users will never spot those warnings and wil
enver report issues, and the autobuilders will not fail and we
will not notice either...

One solution is to add a configuration knob to make that a
hard-error, like we have the paranoid libs/headers check:

config BR2_PPD_OVERWRITE_STRICT bool "Strict file overwrite
detection" depends on BR2_PER_PACKAGE_DIRECTORIES help Say 'y'
here to turn the file overwrite detection to a hard error. By
default, only warnings will be printed.

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 I really think this must be a hard error for PPD builds, and
just a warning for non-PPD builds.

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

So, my preference would be to merge as an unconditional check, and
see how it goes. 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.

I was originally with Yann, but these arguments convinced that it is
indeed better to not have the option (for now).

So I'm one of those actively using TLPD and I'm happy to have this
producing hard errors to find possible issues in my configs as well as
helping to fix them.

So I gave this a spin and immediately found util-linux recompiling some
libs which util-linux-libs already installed. Looking for the reason I
came upon Carlos Santos Commit 8bafc6dc "package/util-linux: build
programs and libraries in separate packages" where the commit msg says
".... Installing util-linux overrides files installed by util-linux-libs
but this is not a problem: it's allowed for a package to overwrite files
from another package, as long as there is a dependency between the two."

So if this is still true, the logic should be changed to take
dependencies into account like suggested in the other discussion.

However, the check also found a conflict where GL/glext.h of mesa3d is
overwritten by gst1-plugins-base. It is a dependency, thus it's
deterministic, but still we probably end up with an unexpected version
glext.h in the SDK, so it's nice that things like this are brought to
attention.

Now the build of our standard qt-demo config is almost done and another
conflict pops up when some kernel modules of Wifi-Sticks are installed.
Of course modules.dep, modules.alias and so on are modified. That will 
have to be taken care of.

However, only 3 problems up to just before the target-finalize step. So
far that's not too aggressive for me.


regards,
Andreas

Regards, Arnout

_______________________________________________ buildroot mailing
list buildroot@busybox.net 
http://lists.busybox.net/mailman/listinfo/buildroot

_______________________________________________
buildroot mailing list
buildroot@busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot