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

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

On Fri, 2020-12-11 at 16:54 +0000, Richard Purdie wrote:
> 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).

Optional doesn't always imply unimportant - for some users it's not
needed, for others it is, so it's optional. We are in the latter group,
hence the work to implement and support it in a multitude of places.

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

I'm sure it wasn't intentional, but this passage comes across as quite
condescending. Everybody involved is perfectly capable of understanding
how this works and what it implies.

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

Could you please be more specific? Dependencies on packages from other
recipes are pretty much normal. In what way is this different?
And most importantly, do you have a suggestion on how would you like to
see this done instead?

> 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 recipe is what it is - I'm not adding this auto-generation of
packages, it was there already, so I have to work with it. If you have
a preference for handling it differently please let me know and I'll
apply it.

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

As already mentioned, the v2 has not only been tested but used in
production for a year. Every subsequent revision is recent, so
obviously hasn't been used yet, but it is also pretty much a 1:1
application of Yocto maintainers requests. I've already asked for a
specific configuration to try, as the basic poky one created by oe-
init-build-env didn't show any issue. The CI infrastructure is
completely opaque and imperscrutable to a casual passerby, so
unfortunately I wasn't able to extract anything usable from it.

-- 
Kind regards,
Luca Boccassi