Re: gcc9 ready for prime-time?

[Roland Illig <roland.illig%gmx.de@localhost>]

On 02.03.2020 16:32, Greg Troxel wrote:
> Jason Bacon <outpaddling%yahoo.com@localhost> writes:
> > On 2020-03-02 03:10, Jonathan Perkin wrote:
> > > For some reason the gcc9 maintainer has decided to take it in a
> > > different direction than all the other gcc packages, so there's no
> > > gcc-libs support and thus no USE_PKGSRC_GCC_RUNTIME support.

Maybe the maintainer of lang/gcc would like to be included in this
discussion. I therefore CC'ed him. Since you know who the maintainer is,
I had expected that any of you would have done this from the beginning.

I took maintainership because no-one else had done so in the 9 months
after GCC 9 had been released. Therefore I thought it would be a
low-priority package and the ideal target for cleaning it up.

I took the different direction because I was annoyed of having the same
31 patches being carried forward in each version again. Of these 31 patches:

11 are ok and have been reported upstream
13 are missing a bug report URL
7 are entirely undocumented

I'm generally fine with the first category, but I decided to start from
scratch because I wanted to know how many patches are really necessary
to build GCC. The patches that have been reported upstream should
probably be copied from gcc8 to gcc9.

The other patches should be reported upstream (if anyone knows why they
exist at all). The GCC packages also show a downside of patching only a
single file per patch. For example, adding the most basic NetBSD support
is split over several patch files from several directories, which makes
it difficult to understand them and submit them in a single GCC issue.

Besides omitting the (to me) unnecessary patches and adding PLIST files
for the platforms where GCC 9 is known to build in a bulk build, I
cleaned up the package Makefile a bit, but these changes are easy to
identify and are local to a few lines above and below each actual
change. There's nothing in it that's completely different.

> > > This and the removal of many important patches makes it useless for
> > > our (Joyent) requirements so we will be implementing our own fork.

I don't know what the gcc-libs packages are used for and who needs them,
therefore I didn't care to add a separate package for gcc9. If you need
gcc9-libs, it should be simple to add and test it. I don't know how I
sould test that this package works as intended.

> > Perhaps we can have a discussion about the reasoning behind the design
> > change and how to make it work.

Sure we can do, that's why I added the maintainer. Having a discussion
about the maintainer's reasoning without asking him at all seems
pointless to me, though.

> That would be useful, and we can then decide on which approach is be
> lang/gcc9, and which has a different name.  Ideally, we'd end up with
> only one package that everyone thinks is ok.

I'm fine with having a single package.

> As for the name, I think if pkgsrc has a standard approach, then gcc9
> should probably be that standard approach.  I don't think first-to-land
> matters much.

Agreed. The gcc9 package should be as usable as all the other GCC
packages. And gcc10 will be released next month.

> My understanding of the gcc9 situation is fuzzy, but:
>
>    1) gcc packages genearally generate PLISTS and gcc9 is explicitly
>    recording them, which is good for safety/understanding, bad for
>    working on untested platforms, and a bit more work.  But I think this
>    is a minor thing that is not the real issue.

This is exactly my reasoning. Citing from the commit message that added
lang/gcc9:

> pkgsrc-specific changes to lang/gcc8:
>
> The PLIST file is fixed, to guarantee that all expected
> files are installed properly. In lang/gcc8 it had been
> autogenerated.
>
> Only those patches have been kept that were strictly
> necessary to build GCC on NetBSD-amd64. The others may be
> added from lang/gcc8 as necessary.

>    2) I really don't understand the lack of gcc9-libs and the ability to
>    use pkgsrc runtime.  I don't understand if people that think gcc9-libs
>    shouldn't exist also think the existence of gccN-libs for N <= 8 is a
>    bug, or not.

I don't care whether gcc9-libs exists or not. I don't need it, therefore
I didn't make a package of it. It's that simple.

>    3) I am unclear on the missing patches.  Perhaps this is illumos
>    support.

And NetBSD support (at least that's what some of the gcc8 patches say).
But since GCC 9 builds fine on NetBSD even without these patches, they
might not be necessary at all. This is exactly what I wanted to find out
by starting from scratch again.

> Regarding point 3, in pkgsrc we are a bit conflicted here; there is a
> duty to report patches upstream and include URLs, but also a duty not to
> break patches when doing upgrades, when that's reasonable.  It becomes

I know that the first duty is documented in the pkgsrc guide. I never
saw the second duty documented anywhere in written form. Does that duty
also apply to patches for which there is no-one anymore who can tell why
the patch is necessary?

> messy when patches aren't sent upstream.  When upstream won't take
> patches or fix minority platform issues, then in pkgsrc it turns into a
> duty to cooperate with the people that maintain those unloved-upstream
> platforms, rather than a duty of the updater to merge them all.  That's
> all general; it would be good to have a clear assessment of the
> situation.
The reason that I didn't add gcc9 to mk/compiler/gcc.mk is simply that I
forgot it.