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