Symlinks in packages are broken

[jpumc]

Creating a package with symlinks in it writes the symlink target instead of the symlink.

[Matthias Klumpp]

Hmm, I thought I fixed a bug like this a month ago...
Looks like this needs a unittest soon :-) (I wonder why I didn't notice the issue yet, since this breaks quite a lot of stuff, basically everything with shared library symlinks)

/me tries to reproduce the issue.

[Matthias Klumpp]

Can you confirm that this bug is solved with the latest Git master version?
(Bundles will need a rebuild, unfortunately, since this was a package-generator bug)

[jpumc]

packaging works fine, installing a package with an unresolvable symlink throws

Could not install software: Unable to set permissions on file '<path to symlink>'. Error: No such file or directory

[Matthias Klumpp]

Hmm, I can't reproduce that here - if you run the testsuite, does it complete without errors?
I used the libfoo.ipk sample package, installed it manually (after removing any previously installed versions) like this:
sudo sudo limba install-local ./tests/data/libfoo.ipk --verbose
No errors reported and the generated symlinks are correct.

[jpumc]

Installing packages with relative symlinks to existing files works properly, packages with symlinks pointing to nonexistent files at install time don't work.

Examples:

lib/
 |- libfoo.so -> libfoo.so.0
 |- libfoo.so.0 -> libfoo.so.0.1
 |- libfoo.so.0.1

Works properly

lib/
 |- libfoo.so -> /app/lib/libfoo.so.0
 |- libfoo.so.0 -> /app/lib/libfoo.so.0.1
 |- libfoo.so.0.1

Doesn't work as /app/lib/libfoo.so.0.1 doesn't exist at install time

[Matthias Klumpp]

Ah, that makes sense - that was a really dumb issue, it is fixed now (and I am thinking about making a bugfix release, the order in which files are extracted is not fixed, and symlinks are very common, so people will likely run into this bug often).
Please check if the latest Git master works for you :-)

[jpumc]

Works fine now.