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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#145477): https://lists.openembedded.org/g/openembedded-core/message/145477 Mute This Topic: https://lists.openembedded.org/mt/78452881/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
