Re: [PATCH 3/3] dtc: Update to version 1.6.1

[Thomas Huth]

On 01/10/2021 11.44, Daniel P. Berrangé wrote:
> On Fri, Oct 01, 2021 at 10:37:51AM +0100, Peter Maydell wrote:
> > On Fri, 1 Oct 2021 at 10:10, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > On Thu, Sep 30, 2021 at 09:10:12AM +0200, Thomas Huth wrote:
> > > > On 27/08/2021 14.09, Thomas Huth wrote:
> > > > > The dtc submodule is currently pointing to non-release commit. It's nicer
> > > > > if submodules point to release versions instead and since dtc 1.6.1 is
> > > > > available now, let's update to that version.
> >
> > > Most of our supported platforms don't have version 1.6.1 available.
> > >
> > > As a general goal IMHO we should be seeking to eliminate bundling of
> > > 3rd party modules that are commonly available in distros. We've
> > > carried dtc for a hell of a long time, and if we keep updating our
> > > submodule we'll keep relyin on new features, and never be able to
> > > drop it because it will always be newer than what's in the distros.
> > >
> > > So personally I think we should never again update dtc and capstone
> > > modules. If we want to take adbantage of new features, then do that
> > > through conditional compilation, as we do for any of the other 3rd
> > > party libraries consumed.

I basically agree, especially for capstone. But for dtc, that also means 
that we cannot compile certain target boards if its not available ... that's 
somewhat more ugly than if there is just a missing backend feature ... but I 
guess it's still ok. Users could always install a recent libfdt first.

> > I agree in general, but (per the commit message here) our dtc
> > submodule is currently pointing at some random not-a-release
> > commit in upstream dtc. We should at least move forward to
> > whatever the next released dtc after that is, before we say
> > "no more dtc updates".
>
> Yep, if we want to fix it onto an official version tag, that's
> OK, just not jumping right to very latest version.

That was the intention here. Accidentally, the first release tag after the 
commit that we are currently using, is version 1.6.1, which also happens to 
be the latest version, too.

> We might want
> to move it backwards to better align with what we're targetting
> in the support

We shouldn't use an older versions as submodule since there was a problem in 
libfdt on Sparc hosts on older versions. All other hosts should be fine with 
version 1.5.1 though (which is what we're indirectly checking in meson.build)

> Best I can tell the distros currently have these versions:
>
>       - Alpine 3.14 - 1.6.1
>       - CentOS 8 - 1.6.0
>       - Debian 10 - 1.4.7
>       - Fedora 33 - 1.6.0
>       - OpenSUSE Leap 15.3 - 1.5.1
>       - Ubuntu 18.04 - 1.4.5
>       - FreeBSD Ports - 1.6.0
>       - OpenBSD Ports - 1.6.0
>       - macOS HomeBrew - 1.6.1
>       - Windows MSys2 - 1.6.0

Thanks! I was just about to collect the same information, too.

So I'd suggest: Update the submodule to v1.6.1 now, so that it points to a 
proper release tag.

Then wait until Debian 10 and Ubuntu 18.04 are EOL (sometime in 2022), then 
we can finally get rid of the dtc submodule an rely on the system fdt 
instead (assuming that versions that are older than 1.6.1 will be fixed by 
the distros on Sparc hosts).

 Thomas