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-leave@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