Re: Problems: Dependencies: v1.2.5

>
> You can post tickets if you register on the trac:
> http://trac.autopackage.org/register
>
> I registered there yesterday, but it said I had insufficient privileges
after clicking "New Ticket" while logged in.  The problem has gone away
today and it looks like I'm now able to create tickets.

> Yes, skeletons and dependencies aren't exactly well documented J. There is
> some info on the wiki, but best way, as usual, is reading the source (of
> makepackage in this case).
>
We might need to look at updating the documentation relatively soon, since
most packagers probably won't bother digging through the source code for
answers.

> 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.
>
I've just installed v1.2.6 and the dependency code works well.  The Quamachi
package even downloads the Hamachi package if necessary, which is very
pleasing.  For the moment, I've added the following to the "Prepare" section
of my specification files:
# TODO: Remove this hack when the AP code is improved
linkFile --nobackup --nolog /usr/lib/libcurl.so /usr/lib/libcurl.so.3

>  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.
>
I'm a big fan of keeping file sizes low, so I'd rather force the user to
download any dependencies manually if the package installation process
can't.

> 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".
>
To have the same effect, I've added the following to the "Meta" section of
my specification files:
AutopackageTarget: 1.2.6

> (1.2.6 is released already, right?)
>
When I checked a few days ago, v1.2.5 was still the current release.  Today
though, the v1.2.6 support code is downloaded when installing the GTK
interface.  However, the front page of the website shows no sign of v1.2.6
and might need to be updated.

> 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
>
Providing an absolute path for the log file seems to have done the trick,
but this conflicts with the default value that's displayed on the
"Packager's Guide" webpage of "./autopackage.log".

> 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.
>
Since I haven't found anything else wrong with v1.2.6, I won't bother doing
this right now.  After I've released the next version of my Quamachi
application, I'll run some tests on v1.4.0.  Thanks for your detailed
response and helpful advice.