Fix LibArchive 3.4.2

[sage-etcher]

• fix url to download correct version
• added configure_options
  • only install shared libraries
  • use Nettle for crypto support
  • use LibXML2 (not Expat) for xar archives
  • build with LZO support
• regenerated the Dependencies file (original works fine atm, as they are already added to the runner by Compile and Scripts's Dependencies, but incase something changes, it's nice to have a more complete list.)

On a base install of Gobo017 it fails to build, as Bzip2 doesn't have libbz2.so created, however, if you re-compile Bzip2, or create the symlink yourself, it'll work nicely even with --pure.

Would also like to note, due to the URL mix-up, Gobo017 comes with LibArchive 3.1.2 installed into the /Programs/LibArchive/3.4.2 folder. This is verified by the archive.h file listing 3.1.2 as the version.

[Nuc1eoN]

On a base install of Gobo017 it fails to build, as Bzip2 doesn't have libbz2.so created, however, if you re-compile Bzip2, or create the symlink yourself, it'll work nicely even with --pure.

Oh, why is that? So on a base installl Bzip2 is not properly symlinked? Would a SymlinkProgram Bzip2 solve it? (Sounds similar to the libCap issue I've had?)

[sage-etcher]

So on a base installl Bzip2 is not properly symlinked? Would a SymlinkProgram Bzip2 solve it?

No it's not a SymlinkProgram issue. Bzip2's main shared library file is at /Programs/Bzip2/1.0.8/lib/libbz2.so.1.0.8, then the following symlinks should point to it: libbz2.so.1.0, libbz2.so.1, and libbz2.so. However the last of them doesn't exist, neither in the /System/Index tree or in the /Programs/Bzip2/1.0.8 tree.

My guess is that when Gobo017 was thrown together that the Recipe for Bzip2 didn't create the symlink, and that sometime after the release, the Recipe was updated to fix that (and to install static Bzip2 libraries which are also missing from base Gobo017)

if you re-compile Bzip2, or create the symlink yourself

was referring to something like this

sudo ln -s libbz2.s.1.0.8 /Programs/Bzip2/1.0.8/lib/libbz2.so
sudo SymlinkProgram Bzip2 1.0.8

[sage-etcher]

My guess is that when Gobo017 was thrown together that the Recipe for Bzip2 didn't create the symlink, and that sometime after the release, the Recipe was updated to fix that

Checked the package's commit history and the previous assumption seems to track

Date (YYYY/MM/DD)	Description	Commit
2020/03/12	Bzip2 1.0.8 Recipe created	Revision Bzip2 1.0.8-r1…
2020/05/24	Gobo017 stable release
2020/10/21	libbz2.so symlink added	Bzip2 1.0.8

[Nuc1eoN]

Indeed, thanks for investigating!

It seems that for such occasions, a system to enumerate new revisions of a package (of the same version could be useful). E.g. Bzip2 >= 1.0.8-1 as a Dependency. However that is currently not a convention on a GoboLinux system.

Merging.

EDIT: Ooops I accidentally prepended the commit with "Bzip2:" rather than "LibArchive:" . I have no force push rights to undo it now, sorry :sweat_smile: Next time, when you do a PR for a recipe, just makes sure to prepend the commit message with eg "LibArchive: [...]". It is not mandatory or anything but that makes it appear a bit more tidy and transparent in the git log I guess:)

[sage-etcher]

It seems that for such occasions, a system to enumerate new revisions of a package (of the same version could be useful)

funny you mention that, was in the middle of writing a wishlist item for that issue, though through different implementation, here. Having something, or anything, in place like it would be quite nice.

Next time, when you do a PR for a recipe, just makes sure to prepend the commit message with eg "LibArchive: [...]"

Understood, apologies!