RE: Problems: Dependencies: v1.2.5

You can post tickets if you register on the trac:
http://trac.autopackage.org/register

 

Yes, skeletons and dependencies aren't exactly well documented :-).
There is some info on the wiki, but best way, as usual, is reading the
source (of makepackage in this case). 

 

Judging on several breaking dependency-related bugs I found in 1.2.x, I
was the first one to actually use dependency mechanism (it was broken in
several places before). In 1.2.6, dependencies are working without any
bugs I know about -- but I was only using sealed packages, and never
tested setting up repository and downloading them.

 

So there might be bugs in retrieving dependencies. You can workaround by
sealing all dependencies into one package (put them into
"autopackage/packages"). You might have to seal-in autopackage support
code and frontend package too. 

 

If you do use dependencies, be sure to switch to 1.2.6 (because of bug
#105), also you should force 1.2.6 as your autopackage target (so that
for users who have previous 1.2.x installed it would update support
code). To force autopackage version edit
/usr/share/autopackage/stub.2.template, and replace
"%AutopackageTarget%" with "1.2.6".

 

(1.2.6 is released already, right?)

 

Debugging in 1.2.5 works for me btw. Running this in terminal will
produce lots of output and a log file (you might want to use absolute
path for logfile though, just in case).

 

export DEBUGLEVEL=3
export AUTOPACKAGE_DEBUG_LOGFILE=/tmp/autopackage.log
package install bla.package

 

If you manage to make debugging work, attach logs to a ticket (or send
them here), so that we know what is wrong, besides curl.so.3 missing.

 

________________________________

From: Chris Giles [mailto:[email protected]] 
Sent: Sunday, January 11, 2009 10:17 PM
To: autopackage-dev-OfajU3CKLf1/[email protected]
Subject: Problems: Dependencies: v1.2.5

 

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