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

Andreas Naumann dev at andin.de
Tue Aug 31 15:35:40 UTC 2021


Hi all,

On 29.08.21 17:01, Arnout Vandecappelle wrote:
> 
> 
> On 29/08/2021 13:39, Thomas Petazzoni wrote:
>> 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"
>> <yann.morin.1998 at free.fr> wrote:
>> 
>>> 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 at busybox.net 
> http://lists.busybox.net/mailman/listinfo/buildroot
> 


More information about the buildroot mailing list