I would expect BuildRequires: pkgconfig(minizip) to continue to work. Seems, following koji info link for minizip-compat-devel-1.2.11-12.fc30.x86_64.rpm: https://koji.fedoraproject.org/koji/rpminfo?rpmID=15302454 it's list of provides includes only: minizip-compat-devel = 1.2.11-12.fc30 minizip-compat-devel(x86-64) = 1.2.11-12.fc30
OK, zlib.spec seems to do this on purpose? %global __provides_exclude_from ^%{_libdir}/pkgconfig/minizip\\.pc$ No rationale given though. I'd argue this is at best unwise, and knowingly breaking stuff
It's intentional because minizip-devel provides that, too. People should start thinking about migration to minizip-devel (the minizip-compat should die soon, upstream totally abandoned that code). See bug 1609830.
But why? Most existing compat packages are counter-examples, of > 1 package providing similar stuff (openssl, compat-openssl). That said, if minizip-devel really provides a break in api, then it's pkgonfig (as well as headers, etc) should be renamed to reflect that and avoid conflicts too.
(In reply to Rex Dieter from comment #3) > But why? To give a clear sign that the package dies, and there's a fork replacement, even though it is not 100% 1:1. > Most existing compat packages are counter-examples, of > 1 package providing > similar stuff (openssl, compat-openssl). > > That said, if minizip-devel really provides a break in api, then it's > pkgonfig (as well as headers, etc) should be renamed to reflect that and > avoid conflicts too. I'm sure about this. We really plan to drop `minizip-compat-*` ASAP, that's not something we have power to take care about. And giving the new minizip.pc different than upstream name would be contraproductive to those who really plan to port against "correct" upstream nowadays. Of course, if there were any volunteers that are OK to take the abandoned 'minizip' part out from zlib.spec and package it separately (under whatever name, and provide pkgconfig(minizip) we'd be probably fine with such proposal.
What package build are we talking about? AFAIK we've successfully rebuilt all the Fedora packages depending on minizip.
I've personally not run into any build issues (though I haven't tried). I only find it... odd that you insisted packagers go through at least 2 waves of changes. 1. switch to minizip-compat-devel 2. then soon after remove that when that could have all been avoided. Marking NOTABUG
The only thing we are sure about is that zlib.git/contrib/minizip is abandoned, and as such it needs to go away from fedora (it's beyond our capacity to maintain it, especially from security perspective). The fact that we'll keep 'minizip-compat-devel' for some time is that porting to the only maintained fork is not trivial. If that was trivial, we'd port directly without the transition period. Any help/suggestion is welcome though with this problem.
I seem to be getting mixed signals: * "we've successfully rebuilt all the Fedora packages depending on minizip." * both old/new packages provide the same pkg-config file implies same/similar api, with little to no changes required * "porting to the only maintained fork is not trivial" implies otherwise I do not dispute that the abandoned code needs to go away. What I've been trying to say, apparently poorly, is that this could have been handled better. IMHO, the new minizip should have been made in a way that was parallel-installable, with a clearly new/different API
> What I've been trying to say, apparently poorly, is that this could have > been handled better. IMHO, the new minizip should have been made in a > way that was parallel-installable, with a clearly new/different API You mean 'minizip-devel' parallel installable with 'minizip-compat-devel', because 'minizip' is parallel installable with 'minizip-compat'. Ok, we could make it parallel installable (+1 for patches, if you think it is useful) but I am not convinced that it would be helpful to the overall situation where we need to clearly push to upstream maintainers to move away from the old code. I wish we had this discussion on @devel before. That said, I really think that 'Provides: pkgconfig(minizip)' should now come from the new minizip-devel package, not from compat one (at least that's what updated code provides, and it should also motivate users to use that if they plan to use libminizip). Btw., my _personal_ opinion is that we shouldn't suggest bundling of the abandoned code in the tracking bug, because that's not a solution for Fedora.