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

Luca Boccassi
2020-12-10T18:48:01Z

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