On Fri, Jun 18, 2010 at 08:14:02AM -0400, Whit Blauvelt wrote: > > Why yes, John, it is. The fine man said outright he didn't believe my honest > account, accusing me of making something up when I was only giving the > facts. He was calling me a liar. He preferred to see my account as a lie so > as not to surrender his faith that Ganglia is a pure and perfect project. > Attitudes like that are dangerous in computing, since they lead to bugs not > being fixed. While KBS could have very well chosen his wording differently he did not call you a liar. That is the interpretation you choose to apply to what he said. If someone tells me that it's going to rain, and I see nothing but blue skies on the horizon and tell them I don't believe them I am not calling them a liar; I am, however, telling them that they are wrong. By this account I find your use of "ignorant" rude and uncalled for. > You installed without a conflict, good. Perhaps you were installing on a > 32-bit system rather than a 64-bit? Perhaps your system didn't have some of > the packages already installed for other functionality that mine did? All I > can say is that, for my system, yum saw version conflicts that were > blockers. Yep, 32-bit. As you didn't point out whether you attempted the 32-bit or 64-bit version I grabbed a test box at random and it happened to be 32-bit. As far as conflicts go I will say again, I didn't have any. And without further evidence from you there's no way to determine why you are reporting alleged conflicts, nor what those conflicts may be. If there are conflicts it's it is much more likely that they stem from self-installs or poorly chosen 3rd party repos then they do with EPEL. > As for "properly," there are, as Larry Wall says, many ways to do it. It is > up to each project, as their first task, IMHO, to see to it that > ./configure, make, make install works for their package, with proper, > documented flags, on standard Linux distros. Ganglia - a fine and valuable > project on the whole - has a broken "make install." But it can be worked > around. Finding workarounds is often a sysadmins job. Sharing those > workarounds with the community is often how free software stays ahead of the > proprietary stuff. This doesn't carry much weight with me when we are talking about an enterprise distro unless the problems are discovered in the process of building SRPMs. By the way, did you report this issue upstream and offer them the workarounds in the form of patches? > On the whole, this list is professional. I like that. But look, > "./configure, make, make install" is _always_ a proper option. Any serious No, it's not. > business will have need of building on occassional program with different > flags than the distro's default, whatever the distro. I often end up And those needs are best met by rolling SRPMs. Heck, you could even give back to the community and make them available for others to make use of. > building a few core applications that way, as do many other sysadmins in > serious business settings. If you don't need to, that's fine. Some > businesses can wear off-the-rack cloths. Others need tailored garments. I don't dispute this at all; it's very true and will remain true. My argument is that building native tarballs and then installing them is *not* the way to go when you are working with a package managed system such as CentOS; take the additional time and make SRPMs that can be properly integrated into the package system. The benefits from such can not be understated and are *well* worth your time. You're not new to the industry so I'm a little confused as to why you don't see this. John -- A nuclear war does not defend a country and it does not defend a system. I've put it the same way many times; not even the most accomplished ideologue will be able to tell the difference between the ashes of capitalism and the ashes of communism. -- John Kenneth Galbraith (1908 - 2006), Canadian-American economist and author, The Ashes of Capitalism and the Ashes of Communism, interview with John M. Whiteley in Quest for Peace: an Introduction (1986) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.centos.org/pipermail/centos/attachments/20100618/c0673934/attachment-0005.sig>