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.
But of course if you do you do not get updates ;) You do however rely on a 3rd party to faithfully provide you correct code based on the version, and host it forever. > 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 how is pip better? > - 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. how is pip better here? > - 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? I think we can skip the checkout in the tarball if we like. If people want to run the test they can checkout then. > - 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. Come on, this is just a test. We *really* don't care if an ISO we use to test ACPI is using an exploitable version of grub. > So in my opinion we should avoid new submodules if there is an alternative. > > Thomas Interesting take generally, but I don't see how the logic applies in this case. Would appreciate hearing your answers to the above. -- MST