Michael Orlitzky posted on Sat, 01 Dec 2012 22:44:36 -0500 as excerpted: > On 12/01/2012 09:48 PM, Duncan wrote:
>> So yes, a news item is reasonable as it's arguably part of that "good >> documentation". But in general, there's something wrong if we're >> unduly worrying about loss of functionality involving a USE flag >> change, or even a simple USE flag default change, because equally as >> arguably, anyone not catching such things with the --pretend/--ask they >> do BEFORE letting things just run, and/or not following up accordingly, >> really should be thinking about a distribution other than gentoo in the >> first place. > I beat my wife, is it her fault she gets beaten for choosing to be with > me? Don't blame the victim. > > Handholding != making an effort not to screw up people's systems. Even > with emerge --pretend, all I'm going to see is that the minimal flag > switched from off to on by default. Which I'll interpret as meaning, > "the minimal flag was changed so that openldap[minimal] today means what > openldap[-minimal] did yesterday." As others have mentioned, equery u[ses] openldap . Anyone who doesn't know gentoo equery (or similar alternative) basics like that really should be looking at a different distro, for the safety and health of their own system, and thus their own health and sanity. It's part of checking out what that USE flag change actually MEANS to them as a gentoo user and gentoo system sysadmin. Of course, whether individual global flags have appropriate per-package descriptions is another question entirely. Unfortunately, openldap doesn't appear to have a local description for the minimal USE flag, and the global description really is NOT adequate if the flag is as important as this discussion indicates it is. That would be a bug in the package, one I'd rate as CRITICAL, given that a change in the value of the flag is here being rated as CRITICAL. I wonder why there's still no such local description for such a critical flag? Unless the maintainer doesn't judge it that critical after all. But that's the bug. Either the flag is critical, or its not. If it is, why isn't there a local description warning how critical it is. If it's not, why this big discussion about changing its default value? But it's exactly this sort of bug that has users who really CARE about their system having to look in the ebuilds (or worse yet, look it up in an N'th level inherited eclass, piecing together the value of variables at runtime by manual logic trace, etc...) to trace the REAL effect of a flag. And even then, sometimes there's no substitute for doing an ebuild ... unpack, then running configure --help in the appropriate dir (or looking at the various auto* files), to see what the configure description actually is for the thing. 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 Hopefully we'll get a description that unambiguously states that it works for both fma3 and fma4 out of that bug; either that or the flag will change to presumably fma4, if it only works for fma4 (which I've tested) and not fma3. Now obviously I don't expect most users to go to /that/ level. I'd expect most users to simply leave the flag disabled if they're unsure. But I WOULD expect most users to SEE the new flag, and investigate at least far enough to see that they can simply leave it off if they don't know whether their system has fma or not. The result might be a bit slower, but it'll work, whereas if they don't have the hardware and turn it on, things might not work. And I'd argue that if they don't care at LEAST enough to investigate to see that the new version will work, either they judge the package not critical enough to their system operation to worry about, or they really SHOULD be looking at a different distro, because they simply don't CARE (or even want to care) enough about their system to safely run gentoo. There's other distros where such decisions are made for them and they don't /have/ to care. Gentoo isn't one of them, nor, I'd argue, SHOULD it be. > Someone's going to reboot three months after this change and their whole > office is going to be down while they try to figure out why they don't > have an LDAP server. For even a small business, that could mean > thousands of dollars. If it's thousands of dollars at stake, then anybody caring about it will surely have taken appropriate measures. Another way of stating that is that if they have NOT taken such measures, then by definition, they do not CARE about the possibility of losing those thousands of dollars! This isn't a new concept. It's the SAME concept that admins are used to dealing with in terms of evaluating whether their backups are sufficient. Yes, people get caught out all the time when things fail and they find out their backup (if any) failed as well, because they never actually tested it, but that's not the distro's problem, nor even the backup device manufacturer's problem, if they weren't following the instructions including the test the backup instructions. > "Ha ha, you shouldn't have trusted me!" is not the appropriate response. In this case like the backup case, it's more like, <shaking head> "Too bad, the documentation was there, but they didn't read and they didn't test before deploying in production. If they'd only done so... Hopefully they can learn from it and next time they'll be prepared, because there WILL be a next time." It's worth noting that "learning from it" may involve EITHER adapting their practices to reality, OR switching to a distro more appropriately matched to their use case. Gentoo isn't for everyone, nor can it be and still be what we know as gentoo. There's no shame in admitting that and encouraging those for whom it's a bad match to go elsewhere... with our blessings! =:^) Meanwhile, my own approach on my own systems is, it's MY system and MY life (or at least ease and comfort) at stake. Yes, I trust gentoo devs not to do anything /insane/, but USE flag changes as they normally appear aren't insane, they're simply routine, and checking what those changes are all about should be just as routine as the changes themselves. I trust gentoo devs to keep their end of the bargain and not change what a flag actually does; I trust MYSELF to use the tools made available to me to detect a change in flags and to act accordingly, because gentoo devs don't know my system, my needs, or my customizations, neither should they be expected to know them. As a gentoo user, which in this context means sysadmin of a gentoo system, that's *MY* job. When package aspects of that customization in the form of USE flags change, portage is very good about displaying and even color-coding the proposed changes, so I can take a look and see how they affect me, and as I said, change anything /unexpected/ to /expected/ in the results, before I give portage the go-ahead to actually do it. If I choose to bypass or ignore that display, that's my responsibility, and nobody but me bears the blame. -- 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
