tech-pkg archive

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

Re: gcc9 ready for prime-time?



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.
>>
>> This and the removal of many important patches makes it useless for
>> our (Joyent) requirements so we will be implementing our own fork.
>
> Perhaps we can have a discussion about the reasoning behind the design
> change and how to make it work.

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.

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.

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.

  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.

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

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


Home | Main Index | Thread Index | Old Index