Main index > Off the wall > libstatgrab & pyststgrab installation in Fedora Core 3

By jeepston (Desklet Author), on Wed Mar 23 15:49:50 2005: libstatgrab & pyststgrab installation in Fedora Core 3.

It took me a while to get everything work on my Fedora Core 3 box. I needed to use some tricks to make it install. So I decided to share my experience with FC3 users.

1. Install libstatgrab as usual:

Code:

$ ./configure
$ make
$ su -c "make install"

2. My tricks:
- copy the package information file (libstatgrab.ps) from the folder it is placed by default (/usr/local/lib/pkgconfig) to /usr/lib/pkgconfig:

Code:

$ cp /usr/local/lib/pkgconfig/libstatgrab.ps /usr/lib/pkgconfig/libstatgrab.ps

- make a symbolic link to the library:

Code:

$ ln -s /usr/local/lib/libstatgrab.so.5  /usr/lib/libstatgrab.so.5

3. And now you can install pystatgrab by the command

Code:

$ ./setup.py install


PS. Does anybody know where I can find description of all functions of libstatgrab?

By syfou (Core Developer & Desklet Author), on Wed Mar 23 16:03:11 2005.

I do not use Fedora Core myself, but by what you did, It means you probably could have used:

Code:


./configure --prefix=/usr


And the rest would not have been needed.

jeepston wrote:


PS. Does anybody know where I can find description of all functions of libstatgrab?

There are a series of man pages that comes with libstatgrab. You can as well read them online.

By jeepston (Desklet Author), on Wed Mar 23 18:40:37 2005.

Well, not every user can predict that it is needed to be done like this. I made default installation w/o specifying the prefix. So I didn't want to go through all the folders, delete all installed files and then install it again to another directory.

So this detour worked for me fine and I'm not claiming that this is the only way to install the lib :) Just one option.

By syfou (Core Developer & Desklet Author), on Wed Mar 23 19:04:37 2005.

Quote:


Well, not every user can predict that it is needed to be done like this.


Well, I guess you are right... Although use of /usr/local as default prefix is not used anymore on most linux distro for about two years now.

Quote:


So I didn't want to go through all the folders, delete all installed files and then install it again to another directory.


That's true since most autotools users do not bother writing the unistall hooks correctly. But there is a solution to that also:

Code:


make DESTDIR=$HOME/temp install



For there, you just have to use a proper find expression on similar on $HOME/temp to automate unsintallation...

But this was just for the sake of arguing... :wink: I understand what your problem was.

By CitizenX (Themer / Graphic Artist), on Wed Mar 23 19:39:37 2005.

Sylvain, you might want to add things like this to the adesklet README, and on the main site somewhere. Like jeepston says, not every user knows about it. Why not give em a heads up? ;)

By syfou (Core Developer & Desklet Author), on Wed Mar 23 19:50:44 2005.

CitizenX wrote:

Sylvain, you might want to add things like this to the adesklet README, and on the main site somewhere. Like jeepston says, not every user knows about it. Why not give em a heads up? ;)

Well, it is not adesklets-related... For this particular issue, the place to mention it would be inside the specific desklets README that use it, and they are not mine right now. Talk to their respective authors about it.

And frankly, I probably wouldn't have thought mentionning it myself right away, as it is common autotools practice... I am not implying people should know this, but... well yes they should. :-D

By CitizenX (Themer / Graphic Artist), on Wed Mar 23 20:36:51 2005.

syfou wrote:


Well, it is not adesklets-related...


I understand that, but seeing as how I see an increasing number of desklets using libstatgrab/pystatgrab, its more than just an individual desklet's problem. If a user has problems with a certain subgroup of desklets (e.g., system monitors), while the problem doesn't lie within the interpreter itself, it is still an adesklet problem as it can possibly affect users' experiences of adesklets itself. I agree it's more of an image problem than anything...but why alienate a group of users (Fedora users using libstatgrab) by shrugging them off onto someone else? I don't think its a problem as of yet, and I agree that you can't test all configurations of every aspect of the installation process or of every dependancy of every desklet...when it's a commonly used tool of many desklets, I would submit that it IS a issue that concerns the project as a whole.

Quote:

And frankly, I probably wouldn't have though mentionning it myself right away, as it is common autotools practice... I am not implying people should know this, but... well yes they should. :-D


While I agree with this (yes people RTFM), there are plenty of ahem...users who don't know this and wouldn't know it was the problem if it wasn't spelled out. Again, I'm not saying that you should explain the whole process step-by-step (Chapter 1: Powering up your System), but when you have a wide audience, you should take in to account those users that don't have as much experience as you would like. I would be disdainful of a project that simply demanded every user know every part of every system and eschewed the problems of 'normal' users that couldn't necessarily code whatever desklet they want. I'm not saying that I'm getting this impression, but it's such a simple thing to add a small line into a README or FAQ as a heads-up (Hey Fedora users, you might want to do this to install libstatgrab if you need it, since many desklets require it.).

By syfou (Core Developer & Desklet Author), on Wed Mar 23 21:30:37 2005.

CitizenX,

while I am sensible to your argument, this is not even a issue with Fedora Core, it's a general issue with the way you install software using autotools on any UNIX system following (even remotely) the Filesystem Hierarchy Standard. Same thing could have happened on any others, with any GNU software - that's far too generic for adesklets' FAQ, as I could think of half a dozen other issues like this one that could as well happen on various systems.

What happended there is that Jeeptson had to circumvent a small mistake by manually rectifying paths between the installation of two packages depending on each others. Normally, the first package should have complained a bit not finding the pkgconfig information in the right place... So, if we really want to help users, we have to make libstatgrab restrict a bit its installation process by including more boundary controls in its autoconf script... I just emailed the authors about it. If I do not get answered within a week, I might even produce and submit them a patch.

I do my best not discriminating less knowledgeable users (I do not talk about you, Jeepston ;-) ), and always provide appropriate answers, either by email, through this forum or through the documentation. For such an issue, I just think the forum is more suited than the FAQ.


adesklets is proud to be hosted on:

SourceForge.net Logo

Back to adesklets.sf.net.