Date: Tue, 31 Jul 2012 17:57:43 +0200 (CEST) From: Gerald Pfeifer <gerald@pfeifer.com> To: Doug Barton <dougb@FreeBSD.org> Cc: Brendan Fabeny <bf1783@gmail.com>, freebsd-ports@FreeBSD.org, Kevin Oberman <kob6558@gmail.com> Subject: Re: lang/gcc46 Message-ID: <alpine.LNX.2.00.1207311746060.2533@gerinyyl.fvgr> In-Reply-To: <5015D122.4040608@FreeBSD.org> References: <CAGFTUwNbj0mDrdu40dwkmECLhrc0Uwap=8UKi=tbBgRCTvZTMQ@mail.gmail.com> <alpine.LNX.2.00.1207300152200.2533@gerinyyl.fvgr> <5015D122.4040608@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 29 Jul 2012, Doug Barton wrote: >> lang/gcc and lang/gcc46 should be fully compatible, without rebuilds >> necessary. Only when lang/gcc is going to move to GCC 4.7 later this >> year would I consider that. > IMO this highlights the issue that unversioned instances of ports that > really need versioning (like gcc) are a bad idea. It's much better for > users to be able to tie their installations to a particular version, and > then only update when they need to. The fact that someday in the future > users who innocently upgrade lang/gcc will suddenly find that everything > relying on libgcc at runtime is now broken pretty much speaks for itself. The fact that I would consider that, was not supposed to imply breakage. :-) I was more thinking better optimization and other benefits. In my day job, we have been doing upgrades from GCC 4.x to GCC 4.x+y run-times quite successfully and without any breakage more than once. And we've got many, quite many, users. In other words, if there is a challenge it's not GCC per se, more our packaging of it (and some work Bapt is doing on the packaging infrastructure should help with that). Gerald
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.LNX.2.00.1207311746060.2533>