[CentOS] Ganglia

[John R. Dennison]

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.sig>