I think the issue is more about space than bandwidth. It's after all only the mirrors that would downloads both base snapshots.
A normal snapshot user would only use one of the bases. On the opposite, it would save some bandwidth, as I'm probably not the only one that has been sometimes downloading the whole package and base folder during package freeze to have something in sync for new installs during the time when base might be out of sync for longer times. -------- Original message -------- From: Theo de Raadt <dera...@cvs.openbsd.org> Date: 07/09/2013 06:13 (GMT+02:00) To: Amit Kulkarni <amitk...@gmail.com> Cc: Lars Engblom <lars.engb...@kimitotelefon.fi>,misc <misc@openbsd.org> Subject: Re: A suggestion for snapshots > 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. Anyone want to pay for a faster network link? Step up -- then we can solve this problem easily.
