On Wed, Sep 28, 2022 at 11:33:52AM +0200, Thomas Huth wrote: > On 28/09/2022 11.26, Michael S. Tsirkin wrote: > > On Tue, Jun 28, 2022 at 12:21:39PM +0200, Thomas Huth wrote: > > > On 28/06/2022 12.03, Michael S. Tsirkin wrote: > > > [...] > > > > For biosbits if we are going this route then I feel a submodule is much > > > > better. It records which version exactly each qemu version wants. > > > > > > As far as I know, you can also specify the version when using pip, can't > > > you? So that's not really an advantage here. > > > > > > On the contrary, submodules have a couple of disadvantages that I really > > > dislike: > > > > > > - submodules do not get updated automatically when doing a "git checkout", > > > we have to update them via a script instead. This causes e.g. trouble if > > > you > > > rsync your source tree to a machine that has no access to the internet and > > > you forgot to update the submodule before the sync > > > > > > - the content of submodules is not added to the tarballs that get created > > > on > > > the git forges automatically. There were lots of requests from users in > > > the > > > past that tried to download a tarball from github and then wondered why > > > they > > > couldn't compile QEMU. > > > > > > - we include the submodule content in our release tarballs, so people get > > > the impression that hte submodule content is part of the QEMU sources. > > > This > > > has two disadvantages: > > > * We already got bug reports for the code in the submodule, > > > where people did not understand that they should report that > > > rather to the original project instead (i.e. you ship it - you > > > own it) > > > * People get the impression that QEMU is a huge monster > > > application if they count the number of code lines, run > > > their code scanner tools on the tarball contents, etc. > > > Remember "nemu", for example, where one of the main complaints > > > was that QEMU has too many lines of code? > > > > > > - If programs includes code via submodules, this gets a higher > > > burder for distro maintainers, since they have to patch each > > > and every package when there is a bug, instead of being able to > > > fix it in one central place. > > > > > > So in my opinion we should avoid new submodules if there is an > > > alternative. > > > > > > Thomas > > > > So looking at the latest proposals downloading files from CI, > > checksumming them etc etc. No auto checkout, not added automatically > > either, right? > > > > This seems to be the only difference: > > - we include the submodule content in our release tarballs > > > > How about we just fix that? Thomas would that address your > > concern at least wrt tests? > > If I'm not forced to checkout that submodule,
I think the make check script can do that? > and if we don't add it to the > release tarball, I guess there's not much left I can complain about ;-) > > Thomas
