On Thu, 2020-12-10 at 18:47 +0000, Luca Boccassi wrote: > On Thu, 2020-12-10 at 15:52 +0000, Richard Purdie wrote: > > On Mon, 2020-11-23 at 13:28 +0000, Luca Bocassi wrote: > > > From: Luca Boccassi <[email protected]> > > > > > > In v2.35 util-linux gained an (optional) build > > > dependency on libcryptsetup. But libcryptsetup build-depends on > > > util-linux for blkid (optional, can be disabled) and uuid > > > (mandatory). > > > Split out util-linux-uuid in a different recipe to break the > > > cycle. > > > > > > Add a packageconfig switch (disabled by default) to allow using > > > the > > > new dependency. > > > > > > https://github.com/karelzak/util-linux/pull/898 > > > > > > Signed-off-by: Luca Boccassi <[email protected]> > > > --- > > > v1: util-linux 2.35 is not out yet, but I'd like to get the > > > preparatory work > > > underway as I'm not sure if this is the best approach or if > > > there are > > > alternatives. Suggestions and comments very welcome. Thanks! > > > v2: changed packages names to reflect old ones (eg: libuuid1 -> > > > util-linux-libuuid) > > > and leave uuid build enable in main recipe to allow for > > > uuidgen build to happen, > > > as it does not have its own autoconf switch. Delete the > > > library manualy from > > > the main recipe after build instead, and add dependency. > > > Might help to break loop python3 -> util-linux -> libselinux > > > -> python3, as it's > > > only libuuid that is needed, see > > > https://lists.yoctoproject.org/g/yocto/message/47570 > > > v3: rebased and refactored to have a common util-linux.inc file > > > > > > > I'm afraid this causes do_package_qa errors in basic testing: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/1668 > > Thanks, added RDEPENDS in v4. Strange that those didn't pop up when > building poky locally, I usually get QA warnings as expected. > Anything > in local.conf to enable to get them?
No, you should see it in a standard build. It did make me wonder how this was tested :/. > > I am worried about this change as we're starting to see a number of > > circular dependencies in util-linux (there is a new bug about the > > pylibmount PACKAGECONFIG option too), maybe we should flag this > > upstream? > > > > Multiple recipes like this usually turn into a maintenance > > nightmare > > unfortunately which is part of my reluctance to go in this > > direction, > > not sure we have any choice though. > > Well I've added the feature, and both the maintainer and myself were > aware of the implications. It's optional, so on distros with multi- > stage bootstrapping functionality like Debian/Ubuntu/RHEL/Suse/etc it > can be automatically disabled for the first stage build. At runtime > it can also be optional via dlopen, if desired (via --configure > flag). I have to ask why libuuid couldn't be done in a separate repository and avoid the need to do a multi-stage build of a component? To me at least, it would seem to make sense to logically split the library code out, then it avoids all the complexity. Yes, that means a different component to release but that isn't unusual. > Yocto could really use multi stage support - this isn't the first and > won't be the last occurrence. Just my 2c... Well, we can do it as you're proving, its just ugly and hard to maintain. I don't think the other distros will be particularly happy about needing to do it either. Outside of libgcc, we've not really found that we need to do this often at all and the compiler/libc interface is a lot more "special" than uuid. Thanks for updating the patch. I'll put it back into the queue and test the new version. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#145458): https://lists.openembedded.org/g/openembedded-core/message/145458 Mute This Topic: https://lists.openembedded.org/mt/78452881/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
