[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-core
Subject:    Re: [OE-core] [DISTRO|MACHINE]_FEATURES_BACKFILL_CONSIDERED: confusing variable names?
From:       "Tom Hochstein" <tom.hochstein () nxp ! com>
Date:       2023-02-28 18:49:33
Message-ID: DB3PR0402MB385242FC81CA153CD9C9F8A2E2AC9 () DB3PR0402MB3852 ! eurprd04 ! prod ! outlook ! com
[Download RAW message or body]

[Attachment #2 (unknown)]



> -----Original Message-----
> From: Richard Purdie <richard.purdie@linuxfoundation.org>
> Sent: Tuesday, February 28, 2023 4:04 AM
> To: michael.opdenacker@bootlin.com; Tom Hochstein
> <tom.hochstein@nxp.com>; OE-core <openembedded-
> core@lists.openembedded.org>
> Cc: YP docs mailing list <docs@lists.yoctoproject.org>
> Subject: Re: [OE-core] [DISTRO|MACHINE]_FEATURES_BACKFILL_CONSIDERED:
> confusing variable names?
> 
> On Tue, 2023-02-28 at 10:52 +0100, Michael Opdenacker via
> lists.openembedded.org wrote:
> > Greetings,
> > 
> > Thank you all for your replies and comments!
> > 
> > On 24.02.23 at 00:24, Tom Hochstein wrote:
> > > I agree. The problem I have with these variable names is that it's ambiguous
> whether the features will be included or excluded from the backfill. All you can
> tell from the names is that the values were 'considered'. What does that mean?
> You have to go to the manual to find the full meaning.
> > > 
> > > What's important about the variables is that they will be 'excluded' from the
> backfill, so this does look much clearer to me:
> > > 
> > > 	DISTRO_FEATURES_BACKFILL_EXCLUDED += "some-feature"
> > 
> > 
> > Richard, would you accept it if I sent a patch replacing
> > "BACKFILL_CONSIDERED" by "BACKFILL_EXCLUDED" in the two variables?
> > 
> > Of course, I can understand if that's too late for the next release, and
> > instead document this oddity, at least before we can make a change again.
> 
> I don't want to rush into this. The idea of the variable was that the
> list were things that distro maintainers would need to consider when
> upgrading and then "mark as considered" so in that context, excluding
> them makes less sense. I'm sure there was discussion about the name at
> the time.

Not sure I understand. When you say 'idea of the variable', are you referring to the \
BACKFILL variable? I assume so since that seems to be the one that the distro \
maintainers will 'consider', right? After they've 'considered' the BACKFILL, then \
they will add the ones they _don't want_ to BACKFILL_CONSIDERED(_AND_NOT_WANTED). The \
ones they _do want_ are not marked.

> 
> I'm nervous about renaming variables in general as it does create pain
> for users upgrading and some community feedback has been that we're
> bordering on frustrating users. I know we have mechanisms now to help
> but it isn't pain free.

This I totally understand 😊

> 
> > > Is there a good reason why we have this separate variable and can't just do
> this?
> > > 
> > > 	DISTRO_FEATURES_BACKFILL:remove = "some-feature"
> > 
> > 
> > Good question. Maybe because ":remove" is final, and cannot be
> > overridden, if I understood correctly?
> 
> Right, the concern would have been it couldn't be undone and the distro
> setups from when this dates from were more complex.

Since every variable is so afflicted by :remove, perhaps this isn't a good argument, \
particularly when there is a more general pattern for this: to add an extra variable \
at the point of the removal:

MY_DISTRO_FEATURES_BACKFILL_REMOVALS ??= "some-feature"
DISTRO_FEATURES_BACKFILL:remove = "${ MY_DISTRO_FEATURES_BACKFILL_REMOVALS}"

> 
> Cheers,
> 
> Richard
> 



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177856): https://lists.openembedded.org/g/openembedded-core/message/177856
Mute This Topic: https://lists.openembedded.org/mt/97187180/4454766
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [openembedded-core@marc.info]
-=-=-=-=-=-=-=-=-=-=-=-



[prev in list] [next in list] [prev in thread] [next in thread]