Hi, I've just updated the Fedora change [1] accordingly.
Feel free to take another look. [1] https://fedoraproject.org/wiki/Changes/MinizipRenaming Lukas On Tue, Sep 6, 2022 at 11:40 AM Lukas Javorsky <ljavo...@redhat.com> wrote: > Hi guys, > > Thank you so much for the feedback. > > Let's wrap it up... > > 1) We will not rename the current "minizip-compat" to "minizip". > > 2) The Obsolete in the "minizip-ng" package will look like this: > "Obsoletes: minizip < 3.0.3" > It shouldn't affect the "minizip-compat" because we won't rename that > (look at step 1) > > 3) The removal of the "Provides" and "Obsolete" in the new "minizip-ng" > package will be removed in Fedora 42 (hopefully at that time all users are > upgraded) > > Note: The rebuild (step 2 in the proposal change) will be done by the > maintainers of the dependent packages. I'll report a bug for each > component, where I will request it. If some of the maintainers will not be > responsive, I will create a PR and as provenpackagers to merge it. > > Is this plan correction okay with you? > Or is there something else you would like to clear out? > > On Tue, Aug 30, 2022 at 11:04 PM Maxwell G via devel < > devel@lists.fedoraproject.org> wrote: > >> On 22/08/30 05:57PM, Zbigniew Jędrzejewski-Szmek wrote: >> > On Mon, Aug 15, 2022 at 05:04:27PM -0400, Ben Cotton wrote: >> > > == Detailed Description == >> > > Upstream has changed the naming of the "minizip" package to >> > > "minizip-ng" and we should follow their naming so there is no >> > > confusion about which package is the right one. Upstream has also >> > > requested to rename the "minizip-compat" zlib subpackage to "minizip" >> > > which is the right naming for the package. >> > > >> > > The "minizip" and "minizip-compat" provides different shared libraries >> > > which prevent us from conflicting sonames. >> > > >> > > The plan behind this change can be put into x steps which will be >> > > completed separately and in the given order: >> > > >> > > ''NOTE: All of the Provides and Obsoletes will be added to the *-devel >> > > subpackages as well.'' >> > > >> > > 1) Create a new package "minizip-ng" which will `Provides: minizip = >> > > %{sameevr}` and `Obsoletes: (minizip < 3.0.2-7 and minizip > 3.0.0-1)` >> > >> > Hi, >> > >> > it seems that Obsoletes does not work with boolean dependencies, >> > so the proposed for would not work. >> >> Correct. And even if it did work, you'd want to use the "with" operator >> not "and." >> >> > Instead, please use the standard form described by the Packaging >> > Guidelines: >> > Obsoletes: minizip < 3.0.3 >> >> That also won't work. If minizip-ng "Obsoletes: minizip < 3.0.3" and the >> new minizip package (the current minizip-compat) is 1.2.12-5, it will >> get Obsoleted by minizip-ng, which is unwanted. I would suggest adding >> "Epoch: 1" to the new minizip package (current minizip-compat) so it >> sorts above 3.0.3. >> >> You also shouldn't add "Provides: minizip = %{sameevr}`" to minizip-ng. >> It will break parallel installability with the new minizip package. Just >> wait to retire the current minizip (the one that's becoming minizip-ng) >> until step 2 has been completed. >> >> > > 2) Rebuild all of the packages that BuildRequire/Require "minizip" >> > > package to BuildRequire/Require new "minizip-ng" package >> >> Who will be doing this? How will it be done? >> >> > > 3) Retire the "minizip" package following the >> > > [ >> https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement_Process/ >> > > Package Retirement Process] >> > > >> > > 4) Wait for the Fedora 40 when it's ensured that every user has >> > > updated at least to the Fedora 38. Remove the `Provides` and >> > > `Obsoletes` from the "minizip-ng" package >> > >> > FWIW, I prefer to keep those for a while. We don't officially support >> > this, but people do upgrades over more than two versions quite often, >> > and it's nice not to break that. >> >> I agree. If you use the approach I outlined above, removing the >> the Obsoletes won't be necessary in order to rename minizip-compat to >> minizip. >> >> > > 5) Rename the "minizip-compat" to the "minizip" package and add >> > > `Provides: minizip-compat = %{sameevr}` and `Obsoletes: minizip-compat >> > > < 1.2.12` >> > >> > As already mentioned in the original discussion thread, this step is >> > risky. We generally try to follow upstream naming on packages, but >> > sometimes it's not possible for various technical reasons. This seems >> > to be one of those cases, because limitiations of Obsoletes mean that >> > we can't obsolete a subset of package versions. >> >> If you use the Epoch approach, this wouldn't be an >> issue. Also, what's the idea of waiting to do step 5 until Fedora 40? >> >> > Minizip-compat is not intended to be used by anything in the >> > distribution, so it's not a big deal if the package name is "wrong". >> > Thus, I think it's better to skip this last step and tell minizip >> > upstream that the we'll keep the "-compat" name for compatiblity >> > reasons. Maybe add a sentence of explanation to the package name. >> >> I agree. While it's possible to overcome the technical hurdles, this >> whole Change seems like more headache than its worth. Kevin and I had to >> deal with a similar situation of Obsoletes and Provides and boolean >> Requires with the ansible -> ansible-core split, and it's been a huge >> pain. This change is probably more complicated than that. It's likely >> that I've confused something in this email given the complexity of a >> renaming like this >> >> -- >> Thanks, >> >> Maxwell G (@gotmax23) >> Pronouns: He/Him/His >> _______________________________________________ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> 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/devel@lists.fedoraproject.org >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue >> > > > -- > S pozdravom/ Best regards > > Lukáš Javorský > > Software Engineer, Core service - Databases > > Red Hat <https://www.redhat.com> > > Purkyňova 115 (TPB-C) > > 612 00 Brno - Královo Pole > > ljavo...@redhat.com > <https://www.redhat.com> > -- S pozdravom/ Best regards Lukáš Javorský Software Engineer, Core service - Databases Red Hat <https://www.redhat.com> Purkyňova 115 (TPB-C) 612 00 Brno - Královo Pole ljavo...@redhat.com <https://www.redhat.com>
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
