All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Pontus Jaensson" <pontus.jaensson@axis.com>
To: bitbake-devel@lists.openembedded.org
Subject: Re: [RFC] Implementation of a submodule fetcher
Date: Thu, 16 Dec 2021 05:36:29 -0800	[thread overview]
Message-ID: <15835.1639661789942932561@lists.openembedded.org> (raw)
In-Reply-To: <6d3f11fb30f39fd9d0f933e92c71d94a59592bbf.camel@linuxfoundation.org>

[-- Attachment #1: Type: text/plain, Size: 1970 bytes --]

Hi Richard,

Thanks for your comments. Regarding your question whether or not the design goals are followed I have the following motivation:

a) Yes, the fetcher follows the same structure as the other fetchers.
b) Done.
c) You can’t for now. DL_DIR is not needed to be inside a layer. Fredrik has two ideas about how to solve it but we would very much want to hear your opinion about any of them is a viable solution. The idea is that it is possible to solve the problem by a symlink or by copying the content of the submodule to DL_DIR. Do you think either of these suggestions can solve the problem?
d) I don’t completely understand this one but once the do_fetch() is done, there is no more network access.
e) It should be. As long as the layer is a git repository and still has its git-database it’s reproducible.
f) done.
g) done.
h) Not yet implemented. I can look up how it is done in other git:// recipes in the meta/layer and do my best to implement it here as well.
i) Should already be done since no new tools are used.
j) Not implemented??
k) Not implemented yet.
l) It does not use any tools.

Regarding your other question why we do need two different fetchers to work with git
submodules I use the same answer as I did to Quentin. All though they are both using submodule I don't think they are related and should have a shared functionality. gitsm:// is allowing a package to have submodules, my version submodules:// is allowing a layer to have submodules. I am aware that the naming is not perfect for the intended purpose and as Fredrik answered you before I am happy to receive suggestions for a better naming. I personally can see a reason for using the submodule:// fetcher but I don't understand why the gitsm:// fetcher is not just an option to the git:// fetcher.

Hope this answered your questions, please come back if you have more or if there is something that I need to explain further.

Best Regards
/ Pontus

[-- Attachment #2: Type: text/html, Size: 2276 bytes --]

      reply	other threads:[~2021-12-16 13:36 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-15 14:24 [RFC] Implementation of a submodule fetcher Pontus Jaensson
2021-12-15 14:42 ` [bitbake-devel] " Quentin Schulz
2021-12-16 13:37   ` Pontus Jaensson
2021-12-15 14:44 ` [bitbake-devel] " Alexander Kanavin
     [not found]   ` <5d35085259c04e5a9e0177430f316dd6@axis.com>
2021-12-16  8:15     ` Alexander Kanavin
2021-12-16  9:16 ` Richard Purdie
2021-12-16 13:36   ` Pontus Jaensson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=15835.1639661789942932561@lists.openembedded.org \
    --to=pontus.jaensson@axis.com \
    --cc=bitbake-devel@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.