On Thu, 2020-05-21 at 09:07 +0200, Jacob Kroon wrote: > Hi, > > I brought this up on IRC with Ross, the question was if > *_BACKFILL/*_BACKFILL_CONSIDERED are necessary nowadays. I used > > DISTRO_FEATURES_remove = "ldconfig" > > and even though I did not add it to > DISTRO_FEATURES_BACKFILL_CONSIDERED, > I did seem to have successfully removed it from DISTRO_FEATURES. I'm > assuming it is because the _append/_remove operators are always > applied > at the end of any variable expansion, thus they are applied after > the > python magic in base.bbclass. > > The _BACKFILL/_BACKFILL_CONSIDERED magic was added in OE-Core in > 2012, > commit 738658d9d5ddef026d2929188744aa225324bf26. > > The _remove datasmart operator was added to Bitbake in 2013, commit > 9c91948e10df278dad4832487fa56888cd58d187. > > It looks to me like the _BACKFILL code was added so that new default > values could be added, without breaking existing distro conf's that > used > the '='-operator to set distro features. But isn't this a general > problem for any variable that is set in user conf-files ? Why > special > handle DISTRO_FEATURES and MACHINE_FEATURES ? Could we just remove > the _BACKFILL magic ?
Back then, people were quite upset when changes made to the default DISTRO_FEATURES changed their builds in ways they didn't opt in to. The options were either a) never change DISTRO_FEATURES or b) add in a mechanism to allow us to make changes. We went for b) and it has eased transitions in that time. We have in general tried to avoid changing DISTRO_FEATURES and the project has stablized in the intervening years too, that variable was quite new back then, its years old now. This is a similar issue to the recently discussed PACKAGECONFIG defaults on, just at a core vs recipe level. I think in both cases we expected users to specify a specific set whereas the way things have worked out, people specify additions and removals (not least as removals were not a thing when we originally wrote this as you mention). I really do not want to see distro layers using _remove as it is an operator of last resort, they work for the final user and the final user alone. If they're part of the distro config, the end user cannot override them which goes against the way layers are supposed to work. Consider how you could undo your removal of ldconfig as a user of a distro? I suspect we need: a) stronger documentation about how antisocial _remove is. b) to consider whether we should "ban" _remove from YP Compat layers? I know even core has some these days although I have tried very hard not to let them in. c) document a policy on how users are expected to configure some of these things I can see the case for removing the BACKFILL 'magic' but I'm not sure I want to encourage widespread use of _remove in distro layers. I think we need some bigger plan about how to handle this issue better more generally, which in turn could resolve some of this. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1076): https://lists.openembedded.org/g/openembedded-architecture/message/1076 Mute This Topic: https://lists.openembedded.org/mt/74369459/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
