[gentoo-dev] Re: RFC: new "qt" category

[Duncan]

Ben de Groot posted on Sun, 20 Jan 2013 16:24:14 +0800 as excerpted:

> On 20 January 2013 00:48, Duncan <1i5t5.duncan@×××.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