Michael Orlitzky posted on Sun, 02 Dec 2012 11:02:09 -0500 as excerpted: > On 12/02/2012 04:40 AM, Duncan wrote: >> >> As others have mentioned, equery u[ses] openldap . >> >> > Does nothing in this case.
It gives the global description, which as I said elsewhere, for a flag that's as critical as people are saying this one is, is an equally critical bug. So that critical bug should be fixed. It's trivial to fix, but solves that problem. I *WOULD* suggest that the default for the package *NOT* be changed as long as the description is as global-fuzzy as this one is, as critical as it is, but the changes could be made at the same time. No problem. >> Actually, I have a bug open at this very moment about a new ambiguous >> USE flag, USE=fma, in the new sci-libs/fftw-3.3.3 ebuild. My bdver1 >> has fma4, but not fma3. Does it apply? I checked the flag >> description, no help. I checked the ebuild, it just use_enables fma. >> On the bug, I've actually tested and found it works for my fma4 >> hardware, and I've posted on the amd64 list asking someone with fma3 >> (probably an amd trinity apu machine, at this point) to test it as >> well. >> >> https://bugs.gentoo.org/show_bug.cgi?id=445053 >> Now obviously I don't expect most users to go to /that/ level. > I think you have Stockholm syndrome. I've updated thousands of packages > this month. I cannot do this for each one, and even if I could, there's > a huge (unnecessary) opportunity cost to doing so. As others have pointed out, if you've updated thousands of packages, it's the same packages many times on quite a number of machines. You investigate once, on the first upgrade, probably a test deployment if it's a business with business-critical machines. After that you know what the change is and how it's going to affect other machines you update, without duplicating the investigation for each one. What kind of admin would insist that they had to do the SAME investigation for the SAME package upgrade on each of 100 machines he administers, many of which have very similar configurations and installed package sets? Yet that's effectively EXACTLY what you're arguing. Someone else said 50-some packages upgraded, stable, one month. That's few enough to investigate just the USE flag changes and news items on each of those 50 packages, one investigation per change, spending quite some time on each change since a lot of those upgrades won't have ANY changes, and still do it in a few hours (maybe half a day twice) a month. Meanwhile, if you're handling that many machines, I'd recommend setting up similar config sets with the same flags on each, and doing binpkgs. Then you upgrade the first one, building the binpkgs in the process, then after testing the upgrade, transfer any config changes necessary on that first test upgrade to the others, then binpkg upgrade the others. > At the very least, my company has to pay my salary. If I were to spend a > week reading the ebuilds for every update I do, that would also waste > thousands of dollars of their money. Yes, if you're spending a week doing it, it WOULD be a waste. Do the investigation for every package change ONCE, apply the knowledge a hundred or a thousand times over (perhaps with a different application on different configs, but that doesn't mean you have to investigate what the change /is/ again!), and you're probably under an 8-hour day's investigation for the entire month. The rest of the time you're simply applying what you found out with the investigation you did the first time you did that same package upgrade and came across that same change. Even on ~arch doing updates a couple times a week, investigating both THOSE changes, AND checking -rX bump changelogs to see what triggered the -rX bump, AND tracking git whatchanged for the three overlays I run, AND tracking git whatchanged for the few live packages I run, and even with the obsession I have at doing so, I'd estimate it's STILL not over 8 hours of investigation a month, on average. And you're saying it would take you a week? For fewer package changes since you're presumably on stable or at least not running overlays and tracking live-git changes? Yes, that's a waste. But I'm not SAYING take a week to do it. I'm saying apply the investigation done on the FIRST machine upgraded, to ALL of them. Even where the configs differ and you make different changes as a result, you can still use the knowledge gained from the investigation on the first upgrade, on subsequent upgrades. > I don't buy the false dichotomy that I should leave Gentoo rather than > trust things not to break without warning. The false dichotomy would be between having to spend a week, repeating the same perhaps 20 investigations over and over thousands of times, just to keep reasonable tabs on what's going on with your updates in terms of config changes, and having to leave gentoo because you /can't/ spend a week a month doing what /should/ take a day (or less), if you applied the knowledge from the first time you upgraded a package to all the /other/ times you did the /same/ package upgrade with the /same/ change in USE flags, etc, to deal with. -- 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
