[[oe] Splitting meta-oe?] On 18.02.20 (Tue 10:45) Burton, Ross wrote: > Hi, > > Is now a good time to talk about splitting up meta-oe? Some layers are > actively developed and maintained (one example: meta-python), others are > basically bitrotting and only get touched when something else causes them > to break world builds (one example: meta-gnome). I've long felt that > meta-oe should be split up and the high quality layers managed in their own > repositories so patches to them don't get held up by breakage in other > sub-layers.
Way back when I first proposed creating meta-networking I pitched it as a separate layer managed outside the meta-oe umbrella. At the time I thought it made sense for my use case and for the use case I anticipated from consumers of meta-networking packages both for the reasons you state below and because my intent was to create a layer primarily useful for creating network-centric devices (bridges, firewalls, switches, APs, etc.) with an absolute minimum of other layer dependencies. I think I actually proposed the highly ambitious goal of oe-core + meta-networking as a functional set. Anyway, in the intervening time there's been enough situations crop up that now the minimal set is something like oe-core + meta-oe + meta-perl(we're still open on that, I think) + meta-python + meta-networking. So my original goal of keeping meta-networking largely independent of other layers isn't practical (wasn't from get-go, really) and I'm okay with that. I also think there's considerable value in being able to say "we don't need that recipe in this layer, it's already maintained by someone else in a common area in the same repo, just a different layer". I wouldn't want to start down a path that leads to multiple incompatible versions of recipes being maintained in layers purely out of convenience to the layer maintainer. I can see a lot of value in removing old recipes / layers that aren't being used and / or have fallen far out of date, though. If you've got a list of those you'd like to discuss, I'm sure that's a useful discussion to have. I'll also take the opportunity to plug my old patch for flagging recipes as deprecated (https://patchwork.openembedded.org/series/5489/). It's never gotten any traction, but I think it's a good early-warning for consumers of recipes that are quietly using them with reasonable success as-is despite any issues the maintainers may have with them. Could be a good way to determine who actually cares about these problem child recipes before they become a big enough headache that we just need to abandon them. -J. > Another advantage of splitting out the high quality layers is that we'd > like to look at running more community layers through the Yocto > autobuilder, and granular layers make that easier to manage. > > Comments? > > Ross -- -Joe MacDonald. :wq
signature.asc
Description: PGP signature
-- _______________________________________________ Openembedded-devel mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-devel
