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)
pgpU7FryXu2Br.pgp
Description: PGP signature
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
