Left by Rawhide

You don't hit enter and watch text scroll by for hours (unless you want to); on a modern multi-core system with a few dollars/gigs worth of RAM, you hit enter, hit your virtual-desktop/terminal switch key, and go about your business just as you normally would. When you get to a convenient break in your normal work, you switch back and see where it's at and if it's time to run the config updater.

Really, just as with binary distros, the real human time of an upgrade is generally AFTER the actual update, checking that any customized config still works for the new version, and figuring out where the upstream dev moved the functionality you depended on in the previous version. That's the same regardless of the distribution, binary, scripted-build-from-source, or LFS, you run, with the difference there being whether it's an all-at-once flag-day upgrade, or a rolling upgrade distro with individual updates as they come in. (Personally, I like the rolling upgrade, as when there's a problem with the update, it's much easier to isolate since there's only a few packages that updated at once that it could be. YMMV.)

Now if you're running an old 586-era system with perhaps an eighth gig of RAM, yeah, building from source is going to make using the system for much else somewhat more difficult, but those days are long gone on anything half-current. Even the original single-core Atoms do reasonably well (they /do/ have hyperthreading), as long as they have a gig of RAM to play with and the build is set to idle/batch priority (nice of 19) and you don't go overboard on the number of parallel build jobs. And if your system really IS sub-gigahertz sub-gigabyte pentium era, there's STILL no reason to sit there watching text scroll by unless you get a kick out of it or something, just schedule the updates for overnite or whatever.