Re: [PATCH 3/3] nativesdk-glibc: Split glibc and libcrypt to use libxcrypt instead

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Sat, 2018-04-07 at 13:36 +0000, Joshua Watt wrote:
> Of course, after this I finished, I think up a new idea :)
> 
> Would it be possible to add libxcrypt to the default dependencies
> (along side glibc)? The main advantage I can see is that it would
> maintain the "status quo" of libcrypt being there be default. My main
> observation from when I went though the exercise of getting this to
> build last night is that while we fixed the SDK for core-image-sato,
> others may be including additional recipes in their SDK that depend
> on libcrypt and these can fail in non-obvious ways (for example,
> util-linux would have been very puzzling to track down if I hadn't
> know it was related to the libcrypt changes).
> 
> We would obviously remove it in the next dev cycle and make the
> recipes fix their DEPENDS, like we are already planning to do.
> 
> It might even be possible to switch the target to using libxcrypt
> this way, but I don't think I would recommend it.
> 
> The main disadvantage that I can think of is that the libxcrypt
> recipe will be ugly, since it would have to build
> with INHIBIT_DEFAULT_DEPS=1.
> 
> I'm not sure I sold myself on this idea. I don't think I know enough
> about all the implications and adding additional nativesdk recipes is
> not very common, so maybe a blurb in the release notes is sufficent?
> 
> Anyway, I thought I would put it out there.

Its not a bad idea but the xcrypt dependencies would get ugly as it
would have to depend on glibc without using the default deps as you
say.

I think we're close to making it work with the virtual/crypt, at least
for nativesdk and since this matches what we'll likely ultimately have
to do, I'm tempted to go that route.

Current patchset is missing a musl PROVIDES but that is easily fixed
for the next test.

Cheers,

Richard