Ben de Groot posted on Sun, 20 Jan 2013 16:24:14 +0800 as excerpted: > On 20 January 2013 00:48, Duncan <1i5t5.dun...@cox.net> wrote:
>> *** (VERY strongly!) Please avoid namespace pollution! Don't drop the >> hyphenated qt-pkg names. As a user, most of the time I DO only refer >> to the package name, and dropping the qt- from qt-core, qt-gui, etc, is >> WAYYY too generic to be practical. I for one would be cursing the >> generic names every time I had to deal with the package. (Tho it's a >> kde upstream issue, the same applies to "the application formerly known >> as kcontrol", now the impossibly generic system-settings, and the >> former ksysguard, now generically system-monitor. Anyone active on the >> kde general or kde linux lists knows I simply refuse to use the generic >> names.) > > And how often do you specifically emerge individual qt modules? These > are usually pulled in as dependencies, and the great majority of users > do not have to deal with this. (Just emerge smplayer, or emerge > kde-meta, or emerge -uD1 @world ...) More often than one might think. =:^] (TLDR folks feel free to skip, the summary is the line above.) Seriously, there's occasional remerges due to USE flag changes or gcc upgrades and full rebuilds, there's -rX bumps, and there's the usual upstream version bumps. While most of these (save for the straght-up same-version remerges) originally appear in emerge -NuDa, thus letting me know they're there, it's not unusual at all for me to pick and choose from the upgrade list and do bits of it at a time for one reason or another. Often, the reason is because I see something changing in the upgrade list, and I'm not thru researching what's going on and how I might need to change the config to accommodate it. I routinely check the ebuild changelogs for -rX bumps before I actually do the upgrade, for instance, because if the gentoo maintainer's doing an out-of-upstream-cycle bump (thus the -rX), there's generally a reason, and part of being a good admin is being aware at at least a general level, what's going on with such things, especially because they might change my desired config, or fix/trigger different bugs than the original package did. Other times I'm still researching new USE flags, or maybe entirely new packages are being pulled into the depgraph, and I don't know yet what's pulling them in and why, when there's a reasonable chance I'll want to change USE flags or the like to avoid the new deps, if I can. Thus I'll often set portage going with a subset of the full upgrade list, the "uninteresting" upgrades or those I've already researched, just to have it working on something in one terminal, while I continue doing my research on other package changes in another terminal window and/or in the browser, looking up bug-numbers, etc. Then of course there's the times when some package or other doesn't build. Given the amount of masked, overlay and prerelease packages I'm often running, this isn't unusual (yesterday's was plasma-workspace from kde 4.9.98, aka 4.10-rc3, when I was doing the .97 -> .98 upgrade; there's a missing extract-only, bug 450708 from 4.9.97 re-opened as it was fixed in that ebuild but the fix apparently didn't make it into the 4.9.98 ebuild). Often, I'll see it fail in the listing in one window (where portage is running with multiple jobs in --keep-going mode), and go try to remerge it in another window, letting it fail again to get the log, then researching and hopefully fixing the problem. When I do, I can now rerun the merge for all the dependencies portage dropped due to the failure, sometimes while the main update is still going. =:^) For these and other reasons it's not unusual in the least for me to be merging specific deep-dep packages by name. (Of course I have -1 in my default emerge aliases/scripts so I don't need to worry about the world file getting screwed up, tho it's empty anyway as everything's in sets.) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
