Problems: Dependencies: v1.2.5

"Chris Giles" <[email protected]> Mon, 12 Jan 2009 16:16:50 +1100
Newsgroups gmane.comp.autopackage.devel
Message-ID <[email protected]>
Hi All

This email is a compilation of my postings to the web forum, as I don't have
the privilege of creating bug tickets.  For those who want to read the
originals, the thread is located here:
http://watteimdocht.de/autopackage/forum/viewtopic.php?f=5&t=44#p152.  As
you can see, Jan-Nik has already provided plenty of support.

Firstly, I'd like to note that I think Autopackage is a great idea. I'm sick
of including RPM/Deb/TGZ packages with my releases and Autopackage is a
sensible solution.

I wanted to modify the default Qt skeleton file, because it doesn't work
with Qt4. I had to search for ages before finding confirmation that I should
put local skeletons into "./autopackage/skeletons/$ROOTNAME". You really
must include this crucial information somewhere within the "Autopackage
Packagers Guide" document.

I've modified the Qt skeleton to also work with Qt4. I'll attach it to a new
thread with the other skeletons I've created in the next few days, once I've
also created some related to my Quamachi application.

I've just tested an Autopackage I created for my Q7Z application on the
following Linux distributions: Arch; Kubuntu; Fedora; Zenwalk. The only
minor issue was that neither the 'su' nor the 'sudo' passwords worked while
installing in Zenwalk. Everything else went well and I'm pleased that I can
finally enforce some dependencies for Slackware users.

Further implementing and testing revealed a new issue relating to the
retrieval of dependencies.  My Quamachi package will depend on a Hamachi
package. In my Hamachi skeleton file within the Quamachi package, I've
included the following line:
Repository: http://quamachi.sourceforge.net/Quamachi/hamachi.xml

In my Hamachi specification file, I've included the following lines:
AutopackageTarget: 1.2.5
URL: http://quamachi.sourceforge.net/Quamachi/
PackageFileName: $SHORTNAME-$SOFTWAREVERSION-$PACKAGEVERSION.package

In other words, the ".xml", ".package" and ".meta" Hamachi files all reside
at that location. Here's the output I got when installing Quamachi:
`--> sudo package install ./quamachi-0.3.6-1.package

# Preparing package: Hamachi GUI
# Checking for Python language runtime ... passed
# Checking for Qt toolkit ... passed
# Checking for PyQt bindings ... passed
# Checking for LogMeIn Hamachi ...
/usr/libexec/autopackage/luau-downloader.bin: error while loading shared
libraries: libcurl.so.3: cannot open shared object file: No such file or
directory
failed
# FAIL: Could not find 'LogMeIn Hamachi'. Try using the native package
manager for  () to install a package with similar name to 'hamachi'.
FAIL: Unable to prepare package Hamachi GUI.

After I created a symbolic link to "libcurl.so.4" as "libcurl.so.3", here's
the output I got when installing Quamachi:
...
# Checking for LogMeIn Hamachi ... passed
FAIL: Unable to prepare package Hamachi GUI.

Since the output isn't verbose enough, I can't know what's going wrong.
Maybe the beers I've had are preventing me from seeing my mistake. Do you
know how I can fix this problem, to retrieve and install Hamachi during the
Quamachi installation? Let me know if you need more info.

I entered the following commands before trying to install the Quamachi
package:
export DEBUGLEVEL=3
export AUTOPACKAGE_DEBUG_LOGFILE=./autopackage.log
export AUTOPACKAGE_TERMINAL_DEBUG=1

There was unfortunately no extra output to the terminal and no log file was
created either. There might be a bug in Autopackage 1.2.5.  In the worst
case, I can enforce this dependency check when installing Quamachi and
require the user to download the Hamachi package manually.

None of the other Linux distributions I'm using have "libcurl.so.3" anymore.
I might upgrade to the latest version of Autopackage and join the mailing
list in case the problem isn't yet fixed. Thanks again for all of your help.


Chris