On Sat, Jun 05, 2010 at 06:48:18PM +1200, Richard Toohey wrote: > On 5/06/2010, at 5:51 PM, Theo de Raadt wrote: > > >> On Fri, Jun 4, 2010 at 7:49 PM, Jacob Meuser <jake...@sdf.lonestar.org> > >> wrote: > >>> I'm still curious how anything left in /usr/obj can be anything > >>> but a possible problem after updating system binaries and sources > >>> to a new release. especially for people who are just "following > >>> the directions as they are written." > >> > >> Do you not agree barring broken makefiles and unreliable system clock > >> (as someone pointed out), object files and binaries (in obj/) should > >> have been rebuilt? > > > > It's a source tree with nearly 40,000 .[chyl] source code files, and > > probably another 40,000 further "source code" dependencies if you > > include manual pages and the perl parts. > > > > We try very hard, and the bsd.*.mk macro package helps a lot > > (enforcing consistancy-because-of-simplicity), but if you think we can > > get all the dependencies right every single time, it is a tough call. > > But this case is worse -- when the trash in the obj tree totally > > mis-matches the src tree since it is so far in the past... that is > > totally impossible. > > > > Dependencies don't help when they don't know about the files. Even > > make clean or cleandir won't help you then. > > > > This was not an installer bug. It had nothing to do with upgrades. > > We've said it before, and I guess we get to say it again: > > > > If don't know what you are doing, install a new snapshot. > > > > How many more times do we have to say that? > > > > Why are people defending a person who thinks they are smart enough, > > and has just proved that they're not? > > > > Miod, Dale, Kurt, Kettenis and I am quite often the first people to > > deal with bumping systems forward over bumps. Some bumps are so > > difficult that after they are done the rest of us jump over them using > > snapshots. When they happen, WE -- THE DEVELOPERS -- USE THE > > SNAPSHOTS! They happen in lots of releases. Why would we use > > snapshots, because we are stupid? Or are we smart enough to not waste > > our time doing things the hard way? > > > > Uwe thinks he's being really clever, but he's not clever at all. He's > > got a record of choosing the hardest paths. That's his problem. I > > just wish he wouldn't be such a loud whiner when he screws his system > > up. > > > But I don't understand what he's doing differently to me. A new release is > out, you want to upgrade from the previous release to the new one, and > then you want to apply the errata patches. > > Not saying I'm doing it perfectly, but I'd like to understand where he's > going wrong because I do something similar - and wrong, from the sound of it. > > I don't want to follow current, I just follow the release & apply errata > patches. > (But it looks like Uwe, I am NOT doing it 100% right.) > > So I was on 4.5, 4.6 came out. I got the 4.6 CD, followed the upgrade > process. > I replaced /usr/src with the 4.6 code off the CD, downloaded the errata > patches, built. > > 4.7 comes out, I upgrade from CD, copied the 4.7 source over, downloaded > errata, built. > > Seems to work most of the time apart from a patch requiring a userland build > (like > openssl) so this is where I am obviously going wrong. > > A snapshot is a point-in-time, may-have-issues, best way to follow current > build, > isn't it? But I'd rather follow release. > > I appreciate you've got better things to do than hand-holding, so I'll work > my > way through it, but any cluesticks appreciated. > > Thanks.
It appears simple enough to me, albeit it's early and I'm not caffeine fueled yet. As part of the any upgrade rm -rf /usr/obj/*, or wherever you are storing the object files. /usr/xobj/*, and /usr/pobj/* too!. By doing the upgrade you have just obliterated any chance of there being a reliable relationship between those object files and the installed programs. Any time you switch between compiling from source and manually dumping object codes and programs onto the system you should start the compile process from scratch to re-establish a known state. After an upgrade, and after you have recreated the /usr/obj, usr/xobj, and /usr/pobj directories as part of recompiling patches, ports, whatever, you should not need to nuke the object directories if you want to save a few minutes of time (on most semi-modern systems). The plan I would recommend is 1) Upgrade. 2) Follow release(8) to generate a coherent source <-> obj <-> program relationship at your desired -release, -stable, -current level. 3) Check that the entire system built without errors. 3) Apply whatever errata you now need. But really, just do a whole system build everytime. If you are fiddling with systems way far away why try to save a few minutes when you can be extra careful? .... Ken
