https://bugzilla.redhat.com/show_bug.cgi?id=2174227 --- Comment #7 from Fabio Valentini <decathorpe@xxxxxxxxx> --- (In reply to blinxen from comment #4) > Updated spec file and SRPM under: > > Spec URL: > https://blinxen.fedorapeople.org/rust-imagequant-sys/rust-imagequant-sys.spec > SRPM URL: > https://blinxen.fedorapeople.org/rust-imagequant-sys/rust-imagequant-sys-4.0. > 1-1.fc37.src.rpm 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_for_binary_packages > > 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@xxxxxxxxxxxx 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 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
