Re: [OE-core] [PATCH v3] util-linux: split uuid in separate recipe to allow bootstrapping

["Luca Boccassi" <luca.boccassi@microsoft.com>]

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 <luca.boccassi@microsoft.com>
> > 
> > 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 <luca.boccassi@microsoft.com>
> > ---
> > 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?

> 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).

Yocto could really use multi stage support - this isn't the first and
won't be the last occurrence. Just my 2c...

-- 
Kind regards,
Luca Boccassi