pkgsrc-Users archive

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

Re: Switching default python to 3.6?



On 31.08.2017 00:42, Greg Troxel wrote:
> 
> Kamil Rytarowski <n54%gmx.com@localhost> writes:
> 
>>> But we're only ~20 days from freeze start, and this structurally matches
>>> some recent destabilizing changes.  In general I'm opposed to signficant
>>> large-scale-impact changes right before freeze, such as (aside from
>>> micro/security updates) upgrading perl, clang, or gtk3, or changing php
>>> versions.  (I realize gtk3 and php haven't caused trouble, and the
>>> fallout from the new clang was minor, but nobody expected perl to cause
>>> trouble, and it really did.  I don't mean to object to progress, just to
>>> separate recovery from progress from the freeze.)
>>
>> I would like to get upgraded clang to 5.0.0, it's going to be released
>> just now or in few days. It has been already released with the latest RC
>> and is busy waiting for feedback.
> 
> I really wonder if clang should be versioned in pkgsc, like gcc.
> Presumably you are talking about changing the clang package, not adding
> a clang5 package.
> 
> I fully expect there to be fallout from clang moving to 5 from 4.  I
> remember, not very clearly, some from 3.3 to 3.4, but I could be off.
> I'm not saying 5 is buggy, but it seems likely that it will catch errors
> in code that weren't caught before and result in build failures.  Or
> perhaps you (or Joerg?) have done a full bulk build with the new clang
> vs the old clang, and know that this worry is unfounded.  Most of these
> issues can probably be fixed fairly quickly, but right before freeze is
> a bad time since it imposes churn on the freeze process.
> 
> 

I've performed quasi bulk-builds to catch problems with Clang/LLVM in
pkgsrc packages with something close to 5.0.0. The only ones were fixed
in pkgsrc, NetBSD-current and backported to -8.

This clang upgrade will involve llvm, clang, lldb, polly etc.

We don't version clang and perhaps we shouldn't unless there is a good
reason like a dependency from an important package. Clang is rather
ascending with the number of supported features, backends, frontends
etc; contrary to GNU toolchain that keeps reducing undermaintained code.

Attachment: signature.asc
Description: OpenPGP digital signature



Home | Main Index | Thread Index | Old Index