On Fri, Sep 6, 2013 at 7:14 AM, Lars Engblom <lars.engb...@kimitotelefon.fi>wrote:
> Quite often the snapshot of the packages and the base system are out of > sync, because naturally, the base has to be built before packages. > > For example in this moment, as I write this, Firefox can not be installed > in a new system installed from snapshots, as the packages are compiled > against an older snapshot (amd64) > > If there are just space on the ftp servers, I would suggest keeping two > snapshots: one complete with both base and packages (always in sync) and > one with just the newest base. This would make life easier for people > following snapshots. > > Regards, > Lasse > > The problem with ports is that even with a build farm, the ports guy has to make sure dpb runs to the end. In the best case, a dpb run WITHOUT problems to the end takes atleast a day with a fast quad core machine. gcc4, JDK 1.6 + 1.7, GTK+2, GTK+3, Qt4, Webkit, Firefox are some of the worst ports in terms of build time and the largest offender Libreoffice which alone takes 4-6 hrs of all quad cores (Xeon E3-1230v2 3.3GHz). I might have missed some offenders, I just built a subset, experienced porters who handle the whole tree know better than me which ones are also worthy candidates. Finding and fixing port problems takes a minimum of 2 and I am guessing typically 4 days to pump out a wholly built ports tree, on a extremely fast arch like amd64. By which time the userland, kernel and xenocara have changed a lot underneath. Hence, you get these mismatches from time to time. It is not catastrophic, solution is to wait for the next snap. Even if the ports build machine untars userland, kernel, xenocara, running dpb again may force rebuilds or sometimes not.
