https://bugzilla.redhat.com/show_bug.cgi?id=2174227
--- Comment #7 from Fabio Valentini <decathorpe(a)gmail.com> ---
(In reply to blinxen from comment #4)
Thanks for the update, I'll run final checks and finalize the review later
today.
> 1. Superfluous License tag in the libimagequant-devel
subpackage:
Thanks for the example! Are the marcos documented somewhere? If not, where
would be the best place to document it?
They are not documented yet (other than in /usr/lib/rpm/macros.d/macros.cargo
itself).
I wanted to give them a bit of time to "bake" before doing that, but it's
been
a while and they work fine, as far as I can tell.
I have a few updates for the Rust packaging guidelines anyway, so I will
probably add a mention of them here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_license_...
> 2. The description says "dual-licensed like pngquant",
but the license metadata is just "GPL-3.0-or-later".
I think with dual-licensed the following is meant [1]:
```
Libimagequant is dual-licensed:
For Free/Libre Open Source Software it's available under GPL v3 or later
with additional copyright notices for older parts of the code.
For use in closed-source software, AppStore distribution, and other
non-GPL uses, you can obtain a commercial license. Feel free to ask
kornel(a)pngquant.org for details and custom licensing terms if you need them.
```
That means that if someone wants to use this code in a non GPL-3.0-or-later
compliant code then he could acquire a commercial license. At least that's
why I understand the from the statement above.
Ok, makes sense. In this case, listing only GPL-3.0-or-later is correct.
> 3. Is the ABI of "old" libimagequant (v2) the same as
the one provided by the "new" one built in this package?
I would assume that because rust (still?) has no stable ABI, the dependent
packages will need to be rebuilt.
True, but this doesn't apply here: The library is built with C ABI, not Rust
ABI.
> assuming the APIs are the same
This is the diff between the main and 2.x branch:
```
> diff libimagequant_main.h libimagequant_2.h
16,17c16,17
< #define LIQ_VERSION 40000
< #define LIQ_VERSION_STRING "4.0.0"
---
> #define LIQ_VERSION 21800
> #define LIQ_VERSION_STRING "2.18.0"
75c75
< LIQ_EXPORT LIQ_USERESULT liq_attr* liq_attr_create_with_allocator(void*
removed, void *unsupported);
---
> LIQ_EXPORT LIQ_USERESULT liq_attr* liq_attr_create_with_allocator(void*
(*malloc)(size_t), void (*free)(void*));
```
From my limited C knowledge I would assume that this is ok?
The answer is probably "it depends" ...
If dependent packages expect these header definitions to be numbers instead of
strings, things will break.
I'm not sure about the liq_attr_create_with_allocator function (or whether
casting function pointers to void* is valid).
However, it appears that the library soname is unchanged
(libimagequant.so.0()(64bit)) even though there are API changes :(
So you will need to rebuild applications (and fix them, if they are affected by
these API changes).
--
You are receiving this mail because:
You are always notified about changes to this product and component
You are on the CC list for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=2174227