Date: Wed, 13 Mar 2002 16:35:34 -0600 From: "Mike Meyer" <mwm-dated-1016490934.1c154c@mired.org> To: swear@blarg.net (Gary W. Swearingen) Cc: "Jeffrey J. Mountin" <jeff-ml@mountin.net>, stable@FreeBSD.ORG Subject: Re: /etc/make.conf question Message-ID: <15503.54326.428721.508750@guru.mired.org> In-Reply-To: <og7kog9kdj.kog@localhost.localdomain> References: <4.3.2.20020312135845.0369fc20@207.227.119.2> <20020312114158.A92910@blackhelicopters.org> <Pine.GSO.4.32.0203121126520.1546-100000@nippur.irb.hr> <20020312074349.A91204@blackhelicopters.org> <20020312155618.GA9463@raggedclown.net> <shk7sha9n2.7sh@localhost.localdomain> <4.3.2.20020313115014.034f9180@207.227.119.2> <og7kog9kdj.kog@localhost.localdomain>
next in thread | previous in thread | raw e-mail | index | archive | help
Gary W. Swearingen <swear@blarg.net> types: > "Jeffrey J. Mountin" <jeff-ml@mountin.net> writes: > > No matter, it's not good to publicly suggest non-standard procedures. Nor is it good publicity to suggest non-standard documentation for things that are documented on the FreeBSD site. But both things happen all the time. > > Matthew's > > "make update buildworld kernel" is even worse as doing an update without > > knowing you are in the middle of a mass commit is one way to break a > > build. > Another way is to use the "standard procedure". It's still not clear to > me how four steps is better than one, at least until I understand how to > avoid the mid-commit problem. I'm not sure what's so bad about it either, Gary. No, one thing - you can't use -j to parallelize it. I suspect -j is a nop for update - there's only one target. I never use it on build or install kernel, but it ought to be ok for those. Using it on kernel is a bad idea. Anyway, if you catch things mid-commit, you're blued and tattooed no matter what you do. Update won't fail. Buildworld or buildkernel may, in which case the standard advice is to update again, and see if the problem is gone. If not, check the lists, and report it if it hasn't been reported, then wait for someone to report having fixed it before trying again. Personally, I like to know *where* something breaks, so I run each of the steps by hand. But like you, I can't see any harm in doing those three steps in one command. > > Better to pull and wait at least a short time before building to ensure > > one has all the commits of a change. > The wait won't ensure that, of course. How DOES one ensure that? Perforce :-) <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15503.54326.428721.508750>