On Thu, Aug 19, 2021, 11:31 AM Konrad Weihmann <kweihm...@outlook.com> wrote:
> > > 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. > Sorry, that was my fault. I was preoccupied and didn't fix it when it was pointed out earlier. FWIW, I do have some WIP changes that use this functionality that will hopefully land soon so it will be used :) > > > > 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 (#154982): https://lists.openembedded.org/g/openembedded-core/message/154982 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] -=-=-=-=-=-=-=-=-=-=-=-
