Sounds like there wouldn't be any noticeable/unfixable effect, then. It's always easy to agree with something when I'm not doing the actual work, of course.
On Fri, Feb 1, 2013 at 11:03 AM, John Marino <[email protected]> wrote: > So > 1) They are broken permanently until A) somebody patches them or B) > somebody updates the package which has a good chance of working with gcc47 > 2) They aren't broken if you use DRAGONFLY_CCVER=gcc44 which we have done > in the pkg themselves for those pkgs hopelessly broken on gcc4.7. The ones > that can be patches do not feature this. That shouldn't stop people from > using DRAGONFLY_CCVER on packages known to previously build. It's a > legitimate technique. > 3) this is the latest excerpt bulk build (follows) > The gnustep-base is a separate multiplatform-disaster. The rest of the > failures are leaf packages. Nothing too major. Building with gcc44 > probably gets you another 100 packages I would think, at most. > > pkgsrc bulk build report > ======================== > > DragonFly 3.3/i386 > Compiler: gcc > > Build start: 2013-01-26 00:26 > Build end: 2013-01-30 20:15 > > Total number of packages: 12037 > Successfully built: 11152 > Failed to build: 149 > Depending on failed package: 72 > Explicitly broken or masked: 598 > Depending on masked package: 66 > > Packages breaking the most other packages > > Package Breaks Maintainer > ------------------------------**------------------------------** > ------------- > devel/gnustep-base 22 [email protected] > graphics/opencv 6 [email protected] > parallel/mpi-ch 5 [email protected] > textproc/cabocha 5 [email protected] > emulators/qemu 4 [email protected] > graphics/kdegraphics3 3 [email protected] > devel/ruby-thrift 3 [email protected] > devel/xulrunner10 3 [email protected] > emulators/wine-devel 3 [email protected] > games/plib 3 [email protected] > > > > > On 2/1/2013 16:40, Justin Sherrill wrote: > >> The only thing I can think of: can you quantify which packages aren't >> building? It sounds like this will break some packages, at least >> temporarily, but I don't know which. >> >> The ideal scenario is to never have anyone need to/care to put >> DRAGONFLY_CCVER into their mk.conf. That might be likely if the >> packages affected are old enough/rarely used enough. >> >
