Quote:
Originally Posted by Miranden
Jamesf,
Thank you, that makes perfect sense. I appreciate your willingness to share your knowledge! I am just getting started in my exploration of programming, and Linux is a hobby (right now). I hope to have such an understanding myself one day.
|
Glad to help. I started in Slackware by installing and spending a lot of time reading here and in /usr/doc/Linux-HOWTOS and /usr/doc/Linux-FAQS. More in Linux-HOWTOS, btw. ;v) The first time I ssh'ed in from work, started an X program running on my home machine with the output window on my Windows work machine was quite a day for me. :v)
Also /usr/doc/_program_name_ (take a look!) contains documentation, help files, sometimes a little, sometimes a lot, for various things installed on your system.
Quote:
|
So in the case of building the Deluge package and libtorrent with the same Slackbuild (the second way), the package would not be listed in /var/log/packages, correct?
|
Not quite. All installed packages get listed in /var/log/packages. The package tools handle doing this and also update /var/log/removed_packages, too. Thinking of a package as either a program _or_ a library is incorrect. One of your packages installed libtorrent (and likely .h files, documentation files, etc.) while another installed deluge and a specific libtorrent that that version of deluge was supposed to require.
Open /var/log/packages/bsd-games-2.13-i486-12 (on my system, bsd-games-whatever on yours). This package contains the programs under /usr/games as well as the man pages for those programs, etc. You're looking at a list of everything installed and where it went by opening the package log.
A package is merely an installable archive of files (like a tar or zip file) with a description file (the .desc file) and a script file (doinst.sh) that does everything specific that the enclosed files need to have done to be considered installed. Like, for instance, the $PATH modified, or .desktop files exposed to xfce and/or kde, or specific groups created, specific users created, or specific permissions set, or files moved, renamed, or deleted.
*EDIT: What makes it an installable archive? Simple, it is an archive in the format understood by the package management tools written specifically for Slackware by the creator(s) of Slackware. Those tools, installpkg, upgradepkg, removepkg, have been improved over the years and now understand .txz files as packages. A few years ago only .tgz files were understood to be packages. Other Linux distributions use "package" formats specifically created/designed by their particular package tools: yum, pacman, emerge, etc. END OF EDIT*
Some packages include everything needed for a particular program including, but not limited to, man pages, program file(s), necessary libraries, info pages, .desktop files, etc.
Some packages install only libraries, some install (like some slackbuilds.org packages) only the program, relying on a base slackware install to supply the necessary libraries.
However, all of them supply a list of all of the files that they've installed. That list is tacked on after the contents of the .desc file in /var/log/packages/_package_name_.
To see the contents of a package file you can use explodepkg (man explodepkg) to extract the contents of the package into a subdirectory without installing the package.
Quote:
|
If so, then I wonder why it would be done that way? Wouldn't that make it harder to see what you have installed on your system, and to upgrade something if necessary? Why not just have libtorrent listed on SBo as a dependency (like Deluge's other 6 dependencies), instead of writing it into the build script?
|
As you've discovered, not all libtorrents are created equal. Further, even if deluge said "go get the libtorrent slackbuild" that doesn't mean that the libtorrent authors haven't moved past that version of libtorrent. Some groups, after updating their library, remove the old version from public view.
Think about it this way: libtorrent guys release version 1; slackbuild maintainer makes a slackbuild for libtorrent v1; deluge guy modifies deluge to use libtorrent v1; slackbuild maintainer makes a slackbuild for deluge and says, "Go get libtorrent from sbo, use that"; everyone is happy. Now the libtorrent guys make significant changes and release v1.1 and, since they don't support v1 anymore, remove v1 from public view. Deluge is now broken for anyone trying to build and install it but still works (of course) for anyone who has already installed it. Now new downloaders can't get the libtorrent version that deluge uses since libtorrent v1 has been replaced by v1.1 and v1 is no longer available.
This sort of stuff really happens. It has happened to me.
Further, if deluge was compiled against a specific commit in libtorrent's version tree instead of a release version then telling people how to get that specific version is a lot more difficult. Remember, the libtorrent maintainer on sbo might not be the deluge maintainer on sbo. And even if he is then he has no control of libtorrent releases and release strategies, or deluge releases and release strategies.
Quote:
Addendum: Now I am confused. Right before I got Deluge working by (I thought) building it with a different version of libtorrent (instead of libtorrent-rasterbar-0.16.11 or libtorrent-r7459, which were not working), I installed the standalone package libtorrent-rasterbar-0.16.3 and it's dependency, GeoIP. I wanted to see if that would make a difference for the error I was getting. It didn't.
I thought I had removed libtorrent-rasterbar-0.16.3 when it didn't work, but in fact I did not. I then decided to build Deluge with deluge-1.3.6 and libtorrent-0.13.0. That built, and when I installed it, it worked with no error. So at this point, I unknowingly had two different versions of libtorrent on my system, and it worked perfectly.
When I discovered what I had done, I removed the standalone package libtorrent-rasterbar-0.16.3. If I follow your explanation correctly, this should have left only the libraries for libtorrent-0.13.0 (which was built with the Deluge Slackbuild that I altered to use this version) on my system. When I did this, Deluge again would not start correctly.
So I thought maybe Deluge needed libtorrent-rasterbar-0.16.3 (and not libtorrent-0.13.0) in order to work. But I did not want two versions of libtorrent on my system, so I removed the deluge package (containing libtorrent-0.13.0) and then built Deluge with libtorrent-rasterbar-0.16.3. When I installed it, it again gave me the error. At this point I had tried both versions of libtorrent separately, but every time I had only one version of libtorrent installed, deluge would not work; when I had them both, everything was fine.
To confirm this, when I reinstalled the Deluge package containing deluge-1.3.6 and libtorrent-0.13.0 and also the standalone package libtorrent-rasterbar-0.16.3, it all worked again.
I hope this has not been too hard to follow. I have tried to be precise to avoid confusion, but in doing so I fear I have written the word "libtorrent" so many times that my narrative will be difficult to read.
The short summary is that it seems to me Deluge will only run when I have two different versions of libtorrent on my system: one that I built Deluge with, and one that I installed as a standalone package. Surely this can't be right. I think I have to figure out what is going on here or I will never understand Linux package management. Can you give me any hints?
P.S. In case you want to ask, yes, I did leave libtorrent-rasterbar's dependency GeoIP during these trials in case that was needed (even though it is not listed as a dependency of Deluge). I tried both with and without it.
@cisneros: I have attached my Slackbuild. You can get the rest of the details of what I have done from this thread. Please let me know if you can get it to work with one version of libtorrent, or if you need both as I seem to. Good luck!
|
There's a lot that might be going on there.
Consider the following:
Code:
james@tardis:~$ ls -l /usr/lib/libcurl*
-rw-r--r-- 1 root root 560784 Jun 23 15:06 /usr/lib/libcurl.a
-rwxr-xr-x 1 root root 1041 Jun 23 15:06 /usr/lib/libcurl.la*
lrwxrwxrwx 1 root root 16 Jul 18 20:34 /usr/lib/libcurl.so -> libcurl.so.4.3.0*
lrwxrwxrwx 1 root root 16 May 22 18:43 /usr/lib/libcurl.so.2 -> libcurl.so.2.0.2*
-rwxr-xr-x 1 root root 162076 Apr 5 20:12 /usr/lib/libcurl.so.2.0.2*
lrwxrwxrwx 1 root root 16 May 22 18:43 /usr/lib/libcurl.so.3 -> libcurl.so.3.0.0*
-rwxr-xr-x 1 root root 226648 Apr 5 20:12 /usr/lib/libcurl.so.3.0.0*
lrwxrwxrwx 1 root root 16 Jul 18 20:34 /usr/lib/libcurl.so.4 -> libcurl.so.4.3.0*
-rwxr-xr-x 1 root root 383064 Jun 23 15:06 /usr/lib/libcurl.so.4.3.0*
james@tardis:~$ ls -l /usr/lib/libdb_cxx*
-rw-r--r-- 1 root root 1674548 Aug 14 2012 /usr/lib/libdb_cxx-4.4.a
-rw-r--r-- 1 root root 850 Aug 14 2012 /usr/lib/libdb_cxx-4.4.la
-rwxr-xr-x 1 root root 1273584 Aug 14 2012 /usr/lib/libdb_cxx-4.4.so*
-rw-r--r-- 1 root root 2174852 Aug 23 2012 /usr/lib/libdb_cxx-4.8.a
-rw-r--r-- 1 root root 977 Aug 23 2012 /usr/lib/libdb_cxx-4.8.la
-rwxr-xr-x 1 root root 1720960 Aug 23 2012 /usr/lib/libdb_cxx-4.8.so*
lrwxrwxrwx 1 root root 15 Feb 2 2013 /usr/lib/libdb_cxx-4.a -> libdb_cxx-4.8.a
lrwxrwxrwx 1 root root 16 Feb 2 2013 /usr/lib/libdb_cxx-4.so -> libdb_cxx-4.8.so*
lrwxrwxrwx 1 root root 15 Feb 2 2013 /usr/lib/libdb_cxx.a -> libdb_cxx-4.8.a
lrwxrwxrwx 1 root root 16 Feb 2 2013 /usr/lib/libdb_cxx.so -> libdb_cxx-4.8.so*
james@tardis:~$
Ignore the .a and .la files for the moment, though they are used in compiling and thus are important to you when you figure out what happened with deluge.
The -> indicates that the file name on the left is "linked" to the file name on the right. The file name on the left is only another name for the file name _and_the_file's_contents_ on the right. For our purposes anything without the -> in the line is a simple file with real contents and not a link. You can read up on soft links and hard links and their differences if you want to later. The implications for rm are a little different for the two types of links.
If I ask for libcurl I get libcurl.so, which points to libcurl.so.4.3.0. I can ask for libcurl version 2 (libcurl.so.2) and I get libcurl.so.2.0.2. If I ask for libcurl.so.2.0.3 I haven't got it, nor any 2 version other than 2.0.2. Similarly for versions 3.0.0 and 4.3.0. If I compile against any libcurl version I end up using the same .a and .la files to do it, so presumably all libcurl versions are similar enough to do that.
Except for compiling the situation is similar for libdb_cxx. Notice how all the links go similarly except for the specific .a and .la files. Apparently 4.4 and 4.8 are different enough that if I need to use either specifically then I also have to compile and link against .a and .la files specific to those versions.
Hopefully you can now cat the files under /var/log/packages dealing with libtorrent, libtorrent-rasterbar, and deluge and figure out what installed what and then ls -l /usr/lib/libtorrent* to see what might be getting used.
*EDIT2: You could also 'grep libtorrent /var/log/packages/*' to see all occurrences of the phrase libtorrent in any package listed in /var/log/packages. You could also 'grep libtorrent /var/log/removed_packages/*' to see any libtorrent version you removed. You could also 'grep -l libtorrent /var/log/packages/*' to see only the file names (package names) that contain the word 'libtorrent' in /var/log/packages. Note carefully that in the last case you might get a file name listed where that file contains the phrase "requires libtorrent". A word to the wise, YMMV, standard disclaimers apply, etc. END OF EDIT2*
You can't tell for sure of course unless you examine the contents of the .tar.gz files (the source code, makefiles, etc.) that you downloaded, extracted, compiled, and made into a package with the help of the .slackBuild files. Remember, the programmer can reference libraries during compiling and running in different ways with different results.
Hope this helps, or at least gives you a few places to start! ;vD
An exercise in soft links:
Code:
james@tardis:~$ echo hi >hifile
james@tardis:~$ cat hifile
hi
james@tardis:~$ ls -l *file
-rw-r--r-- 1 james users 3 Sep 2 18:54 hifile
james@tardis:~$ ln -s hifile byefile
james@tardis:~$ ls -l *file
lrwxrwxrwx 1 james users 6 Sep 2 18:54 byefile -> hifile
-rw-r--r-- 1 james users 3 Sep 2 18:54 hifile
james@tardis:~$ cat byefile
hi
james@tardis:~$ cat hifile
hi
james@tardis:~$ echo bye >>byefile
james@tardis:~$ ls -l *file
lrwxrwxrwx 1 james users 6 Sep 2 18:54 byefile -> hifile
-rw-r--r-- 1 james users 7 Sep 2 18:55 hifile
james@tardis:~$ cat hifile
hi
bye
james@tardis:~$ cat byefile
hi
bye
james@tardis:~$ rm hifile
james@tardis:~$ ls -l *file
lrwxrwxrwx 1 james users 6 Sep 2 18:54 byefile -> hifile
james@tardis:~$ cat byefile
cat: byefile: No such file or directory
james@tardis:~$ ls
Desktop/ Documents/ Downloads/ Music/ Pictures/ Public/ Templates/ Videos/ byefile@ xpl.sh* xpl.sh~*
Now you try it, and then understand what happened. A hint: > to a file deletes the file and recreates it. >> appends to the end of the file. Hint 2: @ following a file shown in a simple ls indicates that the file is the left side of a link -> shown with ls -l
