F38 proposal: Minizip renaming (Self-Contained Change proposal)

[Ben Cotton]

https://fedoraproject.org/wiki/Changes/MinizipRenaming

This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.

== Summary ==
Renaming the "minizip" package to "minizip-ng" and renaming the
"minizip-compat" zlib subpackage to "minizip" to align with the
upstream naming.

== Owner ==
* Name: [[User:ljavorsk| Lukas Javorsky]]
* Email: ljavorsk(a)redhat.com


== 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)`

''NOTE: The versions I choose here are the safe versions that create a
space for possible "minizip-compat" rebases''

2) Rebuild all of the packages that BuildRequire/Require "minizip"
package to BuildRequire/Require new "minizip-ng" package

3) Retire the "minizip" package following the
[https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retireme...
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

5) Rename the "minizip-compat" to the "minizip" package and add
`Provides: minizip-compat = %{sameevr}` and `Obsoletes: minizip-compat
< 1.2.12`


== Feedback ==
Early feedback from the community is possite, the feedback is located
in this 
[https://lists.fedoraproject.org/archives/list/[e-mail].o...
Email thread]

== Benefit to Fedora ==
Fedora should always respect upstream package naming, so the users are
not confused about which package are they installing. This naming
change will align the naming with the upstream.

== Scope ==
* Proposal owners: New package "minizip-ng" will be created, and
several changes in "minizip-compat" package which are described in the
Detailed Description.

* Other developers: Change the names of their BuildRequires/Requires
accordingly.

* Release engineering: No action required
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:


== Upgrade/compatibility impact ==
When following the plan in Detailed Description there will be no need
for manual action. Everything will be handled by the automated dnf
upgrade.


== How To Test ==


== User Experience ==


== Dependencies ==
List of the packages from Fedora 37

=== minizip ===
repoquery --whatrequires "*libminizip.so.3*" | pkgname | uniq

R-libSBML

collada-dom

dolphin-emu

dolphin-emu-tool

java-libsbml

keepassxc

libnuml

librasterlite2

libsbml

libspatialite

libxlsxwriter

minizip-devel

perl-LibSBML

python3-libsbml

ruby-SBML

sigil

vxl

xiphos

zfstream

=== minizip-compat ===
repoquery --whatrequires "*libminizip.so.1*" | pkgname | uniq

chromedriver

chromium

chromium-headless

domoticz

hashcat

libdigidocpp

minizip-compat-devel

springlobby



== Contingency Plan ==
* Contingency mechanism: Remove the builds created and revert shipped
changes. Done by any Fedora packager (preferred by the one who knows
about this change)
* Contingency deadline: Beta freeze
* Blocks release? No
''NOTE: If we don't finish this change to the deadline, it is possible
to just complete this change with the next release.''


== Documentation ==
[https://github.com/zlib-ng/minizip-ng/issues/358 Upstream issue]
[https://bugzilla.redhat.com/show_bug.cgi?id=2037245 Bugzilla tracker]


-- 
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis

[Zbigniew Jędrzejewski-Szmek]

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. Instead, please use the standard
form described by the Packaging Guidelines:
  Obsoletes: minizip < 3.0.3

(This is assuming that minizip-ng-3.0.3 will be the first version
built in koji. Please note that minizip < 3.0.2-7 does NOT cover version
minizip-3.0.2-7.fc37 currently in rawhide.)

>  2) Rebuild all of the packages that BuildRequire/Require
> "minizip"
>  package to BuildRequire/Require new "minizip-ng" package
>  
>  3) Retire the "minizip" package following the
>  [https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retireme...
>  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.

>  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. 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.

Zbyszek

[Maxwell G]

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_Retireme...
>  > 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

[Lukas Javorsky]

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(a)lists.fedoraproject.org&gt; 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_Retireme...
>  > > 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  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

ljavorsk(a)redhat.com
<https://www.redhat.com>

[Lukas Javorsky]

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 <ljavorsk(a)redhat.com&gt; 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(a)lists.fedoraproject.org&gt; 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_Retireme...
> > > > 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(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
> > 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
>
>  ljavorsk(a)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

ljavorsk(a)redhat.com
<https://www.redhat.com>