Re: Problems: Dependencies: v1.2.5

Thanks for the extra info.  My responses are listed below yours.

>  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".
>
  Double check your package, when it is built, it will have
>
> AutopackageTarget: 1.2
>
> makepackage will do this bit of magic, because the idea is that all 1.2.x
> releases are compatible, so 1.2.6 will not update autopackage 1.2.5 in case
> it is already installed on user's machine (but will update 1.1.x). Except
> there is a bug in 1.2.5 (and more on previous 1.2.x) that screws up
> dependencies, so you should force exact version.
>

Yep, I now see your point and I've made this change to the template file.  I
also wish to modify a couple of things I wrote in my earlier email.

I've since discovered that using a relative path for the log file does
work.  The problem was that 'sudo' didn't import the necessary environment
variables.  I need to run "sudo package install" because the presence of my
fingerprint reader generates output that confuses the 'package' script when
it calls for 'root' privileges.

After further testing, I've modified the temporary code that fixes the
'libcurl' issue.  To avoid damaging an existing symbolic link, I've appended
the following code to the "Test" section of my new 'libcurl' skeleton file:
# TODO: Remove this hack when the AP code is improved
if [ "`getFile --name /usr/lib/libcurl.so.3`" == "" ]; then
    linkFile --silent --nobackup --nolog /usr/lib/libcurl.so
/usr/lib/libcurl.so.3
    #ln -s /usr/lib/libcurl.so /usr/lib/libcurl.so.3 2> /dev/null
fi

I hope to finalise the Quamachi release tomorrow, which will allow me to
focus my attention on v1.4.0 again afterwards.