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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#154981):
https://lists.openembedded.org/g/openembedded-core/message/154981
Mute This Topic: https://lists.openembedded.org/mt/84201703/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
