[OE-core] [RFC PATCH 1/2] cross-localedef-native: Add hardlink resolver from util-linux

richard.purdie at linuxfoundation.org richard.purdie at linuxfoundation.org
Fri Aug 16 21:50:22 UTC 2019


On Fri, 2019-08-16 at 14:29 -0700, Khem Raj wrote:
> On Fri, Aug 16, 2019 at 2:25 PM Richard Purdie
> <richard.purdie at linuxfoundation.org> wrote:
> > This was discussed on IRC. We really really want to avoid that as a
> > dependency if we care about build performance. Its really easy to
> > just
> > add that in but the implications are significant :(
> > 
> 
> A captured version of this utility would also mean that we have to
> keep this in sync for bug fixes and security fixes etc. which could
> also be considered as expense, so how much do we lose if util-linux-
> native is brought early into dependency chain?

The tool is being used for a specific purpose at build time. Its not
exposed on target and its use is extremely constrained to a specific
set of files where its behaviour should be deterministic.

As such, yes there are questions about bug fixes and about security but
I don't think its going to be a serious burden. We'd need to carry this
until such times as the host systems we support have hardlink which is
probably a few years out but will arrive.

The impact of having util-linux-native in the dependency graph at this
point is significant. I say that as someone who has done a lot of work
in trimming down the times of our bootstrap process. This is exactly
the kind of dependency I've removed and avoided.

glibc is special in that its the worst choke point on the dependency
graph. Nothing to do with target binaries happens until it is ready and
then gcc-runtime can build. Whilst the locales are split from glibc,
they are still connected in the task graph for packaging purposes so
this is important.

Its been pointed out there are other places where util-linux-native has
crept in, in particular python3-native. My preference would be to
minimise these dependencies rather than use them as a way to justify
adding it here too.

Cheers,

Richard



More information about the Openembedded-core mailing list