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

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

On Fri, 2020-12-11 at 09:51 +0000, Luca Boccassi wrote:
> On Thu, 2020-12-10 at 20:04 +0000, Richard Purdie wrote:
> > 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:
> > 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.
> 
> Because there's no need for the extra complications - again, it's all
> optional features, so bootstrapping is not an issue when the tooling is
> there to support it.
> I'm not a util-linux maintainer so my opinion on the subject counts for
> precisely nothing, but as a contributor and user I'd not be very happy
> if it was stuck to the lowest common denominator.

If its all optional and not that important I start to wonder why we
should bother with it.

My point is there has to be complexity somewhere for this "mutli-stage" 
approach to work. How much of it you see depends on the system and how
it handles it but you'd agree that having a simple more linear
dependency tree *is* simpler and easier to work with than something
which has multiple stages (and more efficient on build resources too).

> > > 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.
> 
> But that's what I'm saying: it doesn't have to be ugly, if the
> infrastructure is there to support it.

I'm sure we (OE) could "hide" it but regardless of whether the code is
hidden or not, its still ugly, not often used and hard to maintain for
someone. We don't want to encourage this though.

> On Debian and derivatives, you just mark the dependency with <!stage1>
> - and that's it. When bootstrapping you start from stage1 and the
> resolver skips those. If the package configure/make scripts are done
> well, by default optional dependencies are skipped if not available and
> if not explicitly set - and util-linux does that.
> In the RPM world, the spec has conditional macros and you set the
> appropriate one at the build config level (eg: in the lower ring
> project on OBS).
> It's not perfect of course, and requires attention, and there are
> complications and gotchas, and things do go wrong at times - but such
> is life in the software world.

Complexity is fine, where it makes sense and is needed. You're failing
to convince me its needed here at all. I believe this does need to be
mentioned to the upstream maintainer as they're probably not aware of
the issues it causes. Obviously someone else will have to do that
though since you believe its "fine".

> 
> > Thanks for updating the patch. I'll put it back into the queue and test
> > the new version.
> 
> Thank you - does the approach of adding RDEPENDS look right? The
> interaction between those variables and the native/nativesdk builds
> still confuses me a lot, and I get it wrong all the time.

I've just looked and to be honest, no, it doesn't look right at all :(.
You're adding dependencies in a recipe where the packages don't exist.

Also, if the recipes are properly structuctred, there should be no need
to do this:

PACKAGES_remove = "util-linux-libuuid util-linux-libuuid-dev util-linux-libuuid-dbg"

The more I look at the patch, the more I'm worried :(. As is, its not
going to work. I'm not even sure how its being tested or can work.

Cheers,

Richard