On 19.08.21 18:06, Richard Purdie wrote:
> On Thu, 2021-08-19 at 16:50 +0200, Konrad Weihmann wrote:
>> I kind of missed out on this change... but I got caught up by reality
>> hard this morning :-(.
>>
>> I currently don't see a reason why zstd is required on the host - only
>> systemd is having a hard dependency against zstd atm, while the other
>> lately added references are just optional PACKAGECONFIGs (and there are
>> plenty of them which have loose ends - in poky and meta-oe)
>>
>> So the question I want to raise: why a hard dependency? wouldn't have
>> been HOSTTOOLS_NONFATAL enough?
>>
>> I mean this is the second hard cut in the project within just weeks and
>> this time it was host related, which is even harder to fix in a timely
>> manner in a corporate environment (basically rolling out changes to all
>> dev installations isn't something I fancy on a Wednesday morning :-( )
>>
>> None of the commit messages somehow mentions, why we all of a sudden
>> need that on the host, instead of building it from sources (which should
>> be possible judging from the latest master sources).
>>
>> And on that note: that the documentation wasn't updated in the same
>> changeset is very unfortunate (not even the crops container where updated)
>
> Sorry the change is a bit of a pain. It has been in master-next for a while
> and we did have to jump through a number of hoops as a project to enable this
> (e.g. adding to buildtools and our autobuilder infrastructure).
>
> The reason we're doing this is that we need to use compression within bitbake
> itself for some of our output files. We've not done this in the past as it is
> a pain to have the host prerequisites however there are multiple places we can
> potentially benefit, such as compressed pkgdata and compressed siginfo files.
> It is also possible we may be able to store a compressed parsed datastore.
>

Thanks Richard, that's explains why it's needed

> The siginfo files and datastore could mean we can improve debugging of a
> number of currently hard to solve problems our users face.
>
> Without this we're unlikely to be able to move forward in these areas. If we
> do it, we open up new development opportunities and potentially improved
> usability. We can't "just build it" as that would mean we can't use it within
> bitbake itself.
>
> Sorry this isn't well described anywhere, it is mainly as we can't yet
> "guarantee" that this will do these things. We do know it won't happen
> unless we try though.

Agree - btw maybe a good opportunity to insist on better commit messages
;-)- just out of interest: is there any guideline, maybe it's worth to
at least link to a commit message guide at
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
or here https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines.
And slightly off-topic, but maybe also worth to do some automation, as
I've seen multiple patches lately, that don't 100% follow the patch
guideline in place.

>
> Master *is* a development branch, not a stable release so things can change.

I've been brave enough to enforce a multi-branch development (just to
keep the bar low when jumping from release to release), maybe I take
that as a personal learning :)

>
> Cheers,
>
> Richard
>