libarchive: add version 3.2.1

[thomas]

• This release fixes several critical bugs, including some with security
  implications.
• Changed to autotool build, provides symlink for compatibility with
  cmake builds.

[pmenzel]

rm ${S} CMakeLists.txt

[donald]

• Maybe their cmake is just broken, libarchive.so.13.2.1 would be the right .so number and .14 and .15 are just junk?
• Why do we need so.14 ?
• The right way to prefer autotools over cmake in bee would be
  BEE_BUILDTYPE="autotools"
  in the bee file.
• I think, -j and /dev/shm/junk shouln't go into a bee file.

[thomas]

Maybe their cmake is just broken, libarchive.so.13.2.1 would be the right .so number and .14 and .15 are just junk?

I guess they have separate maintainers, one for the autotools (the one witha brain), and the guy who incraeses numbers on every minor version

Why do we need so.14 ?

because the former libarchive was build with cmake (see the precedors), and it was linked against

The right way to prefer autotools over cmake in bee would be BEE_BUILDTYPE="autotools" in the bee file.

Thanks for the hint, but IMHO it a bit pointless to proclaim 'the right way' to use a tool that is unmaintained.

I think, -j and /dev/shm/junk shouln't go into a bee file.

I think the preset for '-j' is helpfull, 'caus it says 'you can build the package in parallel mode'.
rest folgt....

[thomas]

... tglof tser

I think, -j and /dev/shm/junk shouln't go into a bee file.

I think the preset for '-j' is helpfull, 'caus it says 'you can build the package in parallel mode'.
Is it the name or the concept of throwing away the user build test ?

[donald]

because the former libarchive was build with cmake (see the precedors), and it was linked against
I've checked (with "libcheck.pl") that and didn't find anything in the system. If a project or user linked against .14, we'd need to keep it of course.

Thanks for the hint, but IMHO it a bit pointless to proclaim 'the right way' to use a tool that is unmaintained.

Its alive: https://github.molgen.mpg.de/mariux64/bee

I think the preset for '-j' is helpfull, 'caus it says 'you can build the package in parallel mode'.

Okay, if you see it like this. I was thinking of somenone rebuilding it on a system without that many cores. If I go on a fat server, I set BEE_MAKEFLAGS="-j xxx" otherwise I don't. The bee file doesn't know, ob what system I am.

Same with /dev/shm : a compile by a user might not just be a test run but an attempt to build it for myself or for a project in which case I set PREFIX. Also "/dev/shm/junk" is a global ressource and would work for the first user only.

[thomas]

at least '/usr/lib/gvfs/gvfsd-archive' uses it (GVFS is the virtual filesystem for the GNOME desktop,spooky -- this brings us to 'sousage').

(rest morgen)

[donald]

True. Good catch! My libcheck was limited to *.so below /usr/lib, because I didn't want to wait while the script is running ldd over every .py and .pyc file :-)

[pmenzel]

Should gvfsd-archive be rebuilt or both library version shipped? For example, Debian just ships libarchive.so.13.1.2.

[thomas]

Rebuilding 'gvfsd-archive' with the proper libarchive would be best i think. But maybe one should look for other users of the 'so.14', and also do a test build of gvfsd-archive.

[donald]

gvfsd-archive rebuild #31 seems okay.

[donald]

The rebuild gvfsd-archive has been disted. No more dependencies on libarchive.so.14 in the system. Please remove the ln -sv libarchive.so.13.2.1 libarchive.so.14 and the BEE_MAKEFLAGS and /dev/shm part from the bee file. Because libarchive-3.2.1-0 has already been installed, we need a new revision (libarchive-3.2.1-1) now.

[thomas]

a fresh bee file will be submitted soon

[pmenzel]

War es Absicht, dass die zwei Änderungen nicht zu einer zusammengefügt wurden?

[thomas]

Noe, das war keine Absicht. Ursprung war wohl mein commit zum master, da hatte ich den richtigen branch verpasst (merke, nicht alle Vorschlaege vom git uebernehmen).