-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Richard,
> When you say "fixed refspec", will that be a definitive sha revision
> or a tag?
> We always force resolution of tags as they tend to cause problems and
> can change
> even if it is bad form.
that's a good point. Actually, Martin and I have just been discussing
this, as we noticed that this point actually got "lost" during our
implementation. We are currently working on fixing this. Good to know
how you handle this. I will keep you posted.
> This is potentially a big issue. Cloning operations during parsing is
> pretty
> horrible. We'd not expect any thing being written out like that
> during a parse.
> It would probably work "ok" for one recipe but if you start getting
> the hundreds
> of git recipes we have in some layers, it wouldn't scale if we
> allowed that :(.
>
> Not sure what to recommend here but it is definitely problematic.
Just to make sure that we are on the same page: This ONLY affects
recipes which use the repo fetcher. And it ONLY clones the repository
containing the repo manifest (which tend to be small in size). So
unless developers start using hundreds of repo-based recipes, which I
find a very unlikely scenario, this should not be an issue.
Unfortunately, I don't see any other way to access the repo manifest
file, as we need to calculate the commit hashes of the git repos
referenced in the repo manifest file. Otherwise, it is impossible for
us to determinate the necessity of an update when SRCREV =
"${AUTOREV}".
However, I see one potential improvement here. Currently the cloning of
the manifest repo is done on a per-recipe basis. E.g. this means if we
have 10 recipes inheriting a bbclass containing a repo fetcher, we will
clone 10 identical manifest repos. We'll work on improving this.
- --
With best regards
Jasper Orschulko
DevOps Engineer
Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
[email protected]
• • • • • • • • • • • • • • • • • • • • • • • • • •
iris-GmbH
infrared & intelligent sensors
Schnellerstraße 1-5 | 12439 Berlin
https://iris-sensing.com/
On Wed, 2021-11-10 at 12:46 +0000, Richard Purdie wrote:
> On Tue, 2021-11-09 at 11:26 +0000, Jasper Orschulko wrote:
> >
> >
> > > e) fetcher output is deterministic
> > > (i.e. if you fetch configuration XXX now it will match in future
> > > exactly in
> > > a clean build with a new DL_DIR)
> >
> > check. When a fixed refspec is set within the recipe, the fetcher
> > will
> > check, if all repositories in the repo manifest are set to a fixed
> > refspec as well and otherwise throw an error.
>
> When you say "fixed refspec", will that be a definitive sha revision
> or a tag?
> We always force resolution of tags as they tend to cause problems and
> can change
> even if it is bad form.
>
> > > f) network access is expected to work with the standard linux
> > > proxy
> > > variables
> > > environment but only in the do_fetch tasks)
> >
> > this should work, as we keep the GIT_PROXY_COMMAND environment and
> > run
> > repo via runfetchcmd(). Not further tested though.
>
> If you're using runfetchcmd that should work.
>
> >
> > > g) access during parsing has to be minimal, a "git ls-remote" for
> > > anin
> > > AUTOREV
> > > git recipe might be ok but you can't expect to checkout a git
> > > tree
> >
> > unfortunately, do to the nature of repo, we need to clone the
> > manifest
> > repo, so that we can run "git ls-remote" on the referenced git
> > repos
> > and therefore ensure that
>
> This is potentially a big issue. Cloning operations during parsing is
> pretty
> horrible. We'd not expect any thing being written out like that
> during a parse.
> It would probably work "ok" for one recipe but if you start getting
> the hundreds
> of git recipes we have in some layers, it wouldn't scale if we
> allowed that :(.
>
> Not sure what to recommend here but it is definitely problematic.
>
> >
> Cheers,
>
> Richard
>
>
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmGLzpwACgkQYgqew07V
MNV3XQf9FDzIq3yihsO5FCEn/QOm7v48VuuOZF/85K6dxRgexCfdHHxkn7zJ0luE
ZxgPDmcXM83HcFh6B5XKis88/vnkU2R+YITgWe9+81l1foQryKTP9u7E2giIHW/F
JpGzxTtTb5F3N0+xjmqnyR7OYEB3TqJ1VFsaLlYdYs/sWaDYbt/9AEtcD39ynCr5
dEEqEgiIk05X03kiNnyUd2jDpy0bAbihqJu7OPzU4zSvNn/+zXRM0CMKDemyONb1
u2lINROQpk98qaVzBTX+uOskQTkMrkRRuuncUY0ggq6pHGz3TRubv15mePYIeLlJ
y2lBBB6O8f/iPesjbvKFa85EeNhdAg==
=4Ewh
-----END PGP SIGNATURE-----
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#158077):
https://lists.openembedded.org/g/openembedded-core/message/158077
Mute This Topic: https://lists.openembedded.org/mt/86840389/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-