I spent a number of hours at one of the local SF clubs turning a desktop into a dual-boot (if they ever need that for anything) CentOS 6.4 system, then trying to install Evergreen, an oss library package.
Can you say, "dependency hell"?
I suspect they wrote it on Ubuntu (this is client/server software, dunno why they'd do that). At any rate, I yum installed the postgresql 9.x package that pgsql has on their official site, and that installed with no problems at all.
Then evergreen. Which wouldn't build, because libmemcache was too old. I tried to build a newer package, after d/l one from the memcache official site.
And *that* wouldn't build, because it wanted something that libevent-devel for CentOS 6.4 didn't provide.
I've got two possible routes, here: a) I can try to build an older, deprecated version of Evergreen, or I can try to build a newer libevent and stuff - some of which, IIRC, kde wants.
Opinions? Suggestions? And if anyone's worked with evergreen, PLEASE TALK TO ME!!!
mark
m.roth@5-cent.us wrote:
I spent a number of hours at one of the local SF clubs turning a desktop into a dual-boot (if they ever need that for anything) CentOS 6.4 system, then trying to install Evergreen, an oss library package.
Can you say, "dependency hell"?
Yes, I know what you mean. A couple years ago I was interested in getting Evergreen packaged for centos. Some parts were rather easy to create an rpm file for, but not others. For me the killer was a perl module that required another perl module. And the second module required the first. I tried creating a single rpm for both, but that didn't work.
At the time the developers were busy enough with other problems that they weren't able to assist me. My only suggestion would be to try to install everything (in- tead of packaging everything) and use cpan modules liberally (something I had tried to avoid).
c
On Mon, 16 Sep 2013, m.roth@5-cent.us wrote:
Can you say, "dependency hell"?
I suspect they wrote it on Ubuntu (this is client/server software, dunno why they'd do that). At any rate, I yum installed the postgresql 9.x
I don't think it is appropriate to be derogatory to other distros. Before yum there was 'dependency hell'. However, bear in mind apt-get is a superior package manager to yum... not my opinion but the opinion of many.
james
James Freer wrote:
On Mon, 16 Sep 2013, m.roth@5-cent.us wrote:
Can you say, "dependency hell"?
I suspect they wrote it on Ubuntu (this is client/server software, dunno why they'd do that). At any rate, I yum installed the postgresql 9.x
I don't think it is appropriate to be derogatory to other distros. Before yum there was 'dependency hell'. However, bear in mind apt-get is a
superior
package manager to yum... not my opinion but the opinion of many.
Let's see, where to begin to respond...
1. This *is* the CentOS list, last time I looked. We don't use apt-get. 2. A fair bit of the system software on ubuntu is several releases newer; therefore, anything written on the current release of that will not run on an enterprise distro for years. 3. Ubuntu is, as far as I can tell, targeted at the desktop user. It is *not* targeted for servers. 4. Finally, yum has nothing to do with this: it's all repo software, not how I get it.
Now, I AM most certainly derogatory about the developers. *Most* large organizations, and larger libraries, are *not* going to be running The Latest Ubuntu, with Unity, or whatever; that *is* who, by default, they're targeting. Now, if the software was intended for home users (and I need to implement a library system for my own library), that would be fine. But it's a bad idea for the actual target audience.
mark
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of m.roth@5-cent.us Sent: 16 September 2013 18:05 To: CentOS mailing list Subject: Re: [CentOS] Evergreen ILS on CentOS?
James Freer wrote:
On Mon, 16 Sep 2013, m.roth@5-cent.us wrote:
Can you say, "dependency hell"?
I suspect they wrote it on Ubuntu (this is client/server software, dunno why they'd do that). At any rate, I yum installed the postgresql 9.x
I don't think it is appropriate to be derogatory to other distros. Before yum there was 'dependency hell'. However, bear in mind apt-get is a
superior
package manager to yum... not my opinion but the opinion of many.
Let's see, where to begin to respond...
1. This *is* the CentOS list, last time I looked. We don't use apt-get. 2. A fair bit of the system software on ubuntu is several releases newer; therefore, anything written on the current release of that will not run on an enterprise distro for years. 3. Ubuntu is, as far as I can tell, targeted at the desktop user. It is *not* targeted for servers.
Ubuntu has both desktop and server versions. Further, it also has Long Term Support versions that are supported for 5 years and are broadly equivalent to CentOS Major versions.
When I was there Google ran its entire server fleet on Ubuntu. I'd say that counts as enterprise servers. If you count AMIs rather than actual instances, Ubuntu is far and away the most popular distro on Amazon Web Services:
http://www.zdnet.com/blog/open-source/is-ubuntu-becoming-a-big-name-in-enter...
4. Finally, yum has nothing to do with this: it's all repo software, not how I get it.
Now, I AM most certainly derogatory about the developers. *Most* large organizations, and larger libraries, are *not* going to be running The Latest Ubuntu, with Unity, or whatever; that *is* who, by default, they're targeting. Now, if the software was intended for home users (and I need to implement a library system for my own library), that would be fine. But it's a bad idea for the actual target audience.
Of those web sites running Linux, more than half run either Ubuntu or Debian (and CentOS barely edges out Ubuntu alone):
http://w3techs.com/technologies/details/os-linux/all/all
So a simple majority of the administrators of those sites would prefer .deb over .rpm packages.
In summary, point 2) above is mooted by the existence of LTS Ubuntu versions, and point 3) is just plain wrong, I'm afraid. But I'll grant you points 1) and 4). :)
Tony.
_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
----- No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6669 - Release Date: 09/15/13
______________________________________________________________________ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com ______________________________________________________________________
On Mon, Sep 16, 2013 at 11:03 AM, m.roth@5-cent.us wrote:
I've got two possible routes, here: a) I can try to build an older, deprecated version of Evergreen, or I can try to build a newer libevent and stuff - some of which, IIRC, kde wants.
Opinions? Suggestions? And if anyone's worked with evergreen, PLEASE TALK TO ME!!!
I haven't worked on Evergreen, but lately I've found need to build some specific packages that were developed on Debian or Ubuntu based distros. My approach has been to create a separate /opt/foreign mount and then rebuild what libraries I could and place them there. It worked, but I wouldn't want to do it for anything big.
If you have a build environment on Ubuntu, I suppose another option would be to statically link everything.
Kwan Lowe wrote:
On Mon, Sep 16, 2013 at 11:03 AM, m.roth@5-cent.us wrote:
I've got two possible routes, here: a) I can try to build an older, deprecated version of Evergreen, or I can try to build a newer libevent and stuff - some of which, IIRC, kde wants.
Opinions? Suggestions? And if anyone's worked with evergreen, PLEASE TALK TO ME!!!
I haven't worked on Evergreen, but lately I've found need to build some specific packages that were developed on Debian or Ubuntu based distros. My approach has been to create a separate /opt/foreign mount and then rebuild what libraries I could and place them there. It worked, but I wouldn't want to do it for anything big.
If you have a build environment on Ubuntu, I suppose another option would be to statically link everything.
No - you misunderstand me. IMO, the developers of Evergreen are on it. I'm on CentOS (this is the CentOS list, right?), and they've got stuff that may not be on ours until 7 comes out. In the meantime... the club would like this software up and working (well, *some* of the club...).
I've no intention of building statically. I wouldn't consider it a big deal to build the stuff over in /usr/local/lib, say, or /opt/evergreen/lib, and set the path in the .configure.
I'm just not sure where I need to *start* building. As I said, I'm now two or three levels down in dependencies. I suppose you're right, and I should build what Evergreen wants, and install it other than the default.
*sigh*
Now I just need to figure out when I can get up to Baltimore again....
Thanks. Sometimes, after spending too many hours fighting a grub that wasn't happy, and a wifi that didn't want to give me an address, and *then* starting on this, your brain skips over the "build it in a separate library path".
mark
-
Carl T. Miller -
James Freer -
Kwan Lowe -
m.roth＠5-cent.us -
Tony Sweeney