On Thu, 2020-01-09 at 12:59 +0100, Pascal Huerst wrote:
> On 09/01/2020 11:51, Richard Purdie wrote> I did look at and think a bit
> about your patch. The trouble for me (as
> > the bitbake maintainer) is that:
> > 
> > a) it isn't clear/obvious from the variable name what it does (or even 
> >    from the code)
> > b) it adds yet more options to the fetcher which increases the test 
> >    matrix and possible ways things can break
> > c) the test doesn't actually test it does what its supposed to (no 
> >    check is made on which output is downloaded for a given revision)
> 
> I certainly wouldn't insist on the name and considered it a proposal,
> but you're right, it's not obvious at all. As for test-ability, I can
> relate to your concerns and understand that you don't want to maintain a
> corner-case like this - Which leads me to the conclusion that we should
> probably rethink our internal concept for release builds...
> 
> > Some of these can be fixed, some are much harder and I can't decide if
> > supporting this kind of edge case is going to be an overall good thing
> > for the project or not. I don't want to give you false hope by fixing
> > c) only to say "no".
> 
> Understandable.
> 
> > Add in Khem's valid concerns about reproducibility and it makes it a
> > tough one even to give feedback on.
> > 
> > If we have a ton of users saying "yes we really need this", that would
> > help but I haven't seen that as yet...
> 
> Fair enough.
> 
> Thanks for your thoughts!

FWIW I do want to see the system used to do things like this. I've kind
of envisaged you'd do it "up front" though. For example it should be
trivial for a script to use tinfoil, iterate through and generate an
include file of the revisions you want, using the fetcher calls.

Yes, its slightly more annoying to generate the config, then build it
but if it stops the core becoming unmaintainable with corner cases,
that could be the right decision.

If you do something like that it would be great to share it so others
can see what you did and be able to build off it...

Cheers,

Richard

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Reply via email to