[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Why we should avoid new submodules if possible

From: Thomas Huth
Subject: Re: Why we should avoid new submodules if possible
Date: Wed, 28 Sep 2022 11:55:24 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0

On 28/09/2022 11.47, Michael S. Tsirkin wrote:
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

- 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.


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?

Yes, currently there are only some submodules that are always checked out: dtc, meson, tests/fp/berkeley-softfloat-3, tests/fp/berkeley-testfloat-3 and ui/keycodemapdb.
And for example the ones in the roms/ directory are not checked out by default.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]