Closed hnez closed 1 year ago
From my perspective it makes more sense to simply drop the backports from master and stick to kirkstone
for kirkstone
.
Sounds good to me.
I will prepare and test separate PR where I remove the kirkstone
compatibility for master
and remove the recipes.
Do we want the updated recipes in kirkstone
or do we want to stick with the ones that are already there in the name of stability?
If we want the updated ones I would change the target branch of this PR to kirkstone
, if not I would just close it.
We could also drop compatibility with kirkstone now. I don't see much benefit in maintaining more than one (current) branch.
@jluebbe there is only master
as 'current' branch, yes.
We should keep 'kirkstone' LTS buildable but it does not necessarily require recent versions. I would assume that stable updates and fixes for most components are provided by the original recipe's meta layers.
For this it would make sense to simply drop the recipes from kirkstone too, since meta-python kirkstone already contains more recent ones.
I've had a look at the recipes provided in kirkstone
s meta-python
and they are indeed also newer than the "backports" provided here.
I am going to close this PR in favor of #30, which just drops the no longer required recipes.
Some of the recipes no longer build on langdale as they are now older than the versions included there and e.g. lack support for newer python versions.
This PR just copies over the recipes. Another approach would be to split-off a langdale branch and just remove these recipes there as they are no longer needed there (they are however still needed e.g. in kirkstone).