On Thu, Feb 28, 2013 at 12:04 AM, Yaakov <yselkow...@users.sourceforge.net> wrote: > On Wed, 27 Feb 2013 14:59:20 +0100, Corinna Vinschen wrote: >> On Feb 27 21:29, JonY wrote: >> > I'm worried that I might break gcc installs if I overlooked something >> > obvious. >> > >> > The upload will be overwriting the .hint files, java and libffi are >> > empty packages (I could not get java to build yet). >> >> I'm not concerend about java (dum di dum), but why is libffi missing? >> >> > I can't figure out >> > how to pack the debuginfo package, it is always empty. >> >> Yaakov might be able to help here. > > Working on it. > >> > Will you be able to rollback my uploads in case something does go wrong? >> >> In theory, yes. If you leave the dependencies in place for the "curr" >> release, then the test release shouldn't interfere and testers will >> have to care for the stuff themselves. Let's assume for a start, that >> downmloaders of a gcc test package know what they are doing. >> >> Another way to distinguish the new gcc from the current on would be >> perhaps to create a "gcc472" package set, distinct from the other gcc >> packages. It could install itself into /usr/local, just for the test >> period. >> Yeah, I know, I know, no official package should install into >> /usr/local. Maybe /opt would be fine for once, too. > > The only way to really test GCC is to throw a lot of software at it and > see what breaks, and short of someone doing a mass rebuild, I'm not sure > that will happen unless it goes stable quickly. I volunteered to put > 4.5 through its paces, but it remained in testing for so long that Ports > almost ended up as a completely forked distro and it took me months to > clean up the mess afterwards. > > > Yaakov
Does cygwin have an automatic package building machinery thing like Fedora? Fedora does mass rebuilds with mingw-w64 often, for instance.