[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Adding sha256 support into jigdo tools (jigdo and jigit)

On Tue, Nov 12, 2019 at 11:37:29PM +0100, Thomas Schmitt wrote:
>while exploring the need for adaptions in the build system of libsofs,
>i wonder whether it is really necessary to create LIBJTE2 in libjte.ver.
>Adding new functions is upward compatible.
>In my libraries i add them to the current (and only) SONAME version.
>Fine check for compatibility happens at compile time by the required
>minimum version (e.g. iso_libjte_req_* versus LIBJTE_VERSION_*) and
>at run time by calling libjte__is_compatible().
>If libisoburn gets a configure.ac test for existence of
>libjte_set_checksum_algorithm(), a compiler macro to enable its use,
>and a configure option to disable it despite being available,
>then it can even be built with the older libjte.
>(Fully autostylish.)
>So how about this in libjte/libjte.ver ?
>   global
>   ...
>     libjte_get_next_message;
>     libjte_clear_msg_list;
>+    libjte_set_checksum_algorithm;
>+    libjte_set_checksum_path;
>+    libjte_add_checksum_demand;
>+    libjte_decide_file_jigdo2;
>+    libjte_write_match_record2;
>   local:
>     *;
> };

Surely that works for upwards compatibility, but won't stop somebody
from building and depending on the newer libjte2 then trying to run a
binary with libjte1?

>(Good news is that even libjte2 would probably not cause changes in the
> build system of libisofs. Currently it depends only on <libjte/libjte.h>
> and on libjte.so. I hope that both can keep their names.
> debian/control depends on libjte1 indirectly via libjte-dev.
> Adding "(>= 2.0.0)" would not really be necessary.)

Yeah, that side's easy.

Steve McIntyre, Cambridge, UK.                                steve@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

Reply to: