Minizip renaming Fedora Change

[Lukas Javorsky]

Hi fellow contributors,

Upstream has reported a request for minizip naming change from "minizip" to
"minizip-ng" (minizip-ng is the official name of the upstream package right
now).

As Fedora should match the upstream naming, I believe this change is
necessary.

Another naming change is required for the "minizip-compat" package which is
the subpackage of the "zlib" package. Upstream requests that we should
rename "minizip-compat" to "minizip".

I agree with renaming this package as well, however, this could lead to
multiple confusions maybe even conflicts for the users. The problem with
renaming this package right after renaming the "minizip-ng" could be that
the users may be confused about which package is the right "minizip" for
them.

I believe we could rename the "minizip-compat" to the "minizip" after some
larger time period so every package that requires "minizip" changes the
requirements to "minizip-ng" and there is no confusion anymore.

The first step I want to do is to create a Fedora Change, which contains
this whole process and is well communicated within the community.

This email serves as a heads-up and also opens a possibility for any tips
that you can give me with this change. This is my first time doing a change
like this so it may have some bumps along the way, but I'm willing to learn
and improve, so feel free to give me any advice you think could benefit me
with this process.

Thank you for understanding and sorry for quite a long email.
Lukas

[Marcus Müller]

The latter change seems unwise. Packages which now depend on minizip (to be minizip-ng) 
will continue to do depend on whatever Provides(minizip); if you rename the zlib 
subpackage to minizip, they will depend on the wrong thing.

Cheers,
Marcus

On 28.07.22 10:31, Lukas Javorsky wrote:
> Hi fellow contributors,
>
> Upstream has reported a request for minizip naming change from "minizip" to "minizip-ng" 
> (minizip-ng is the official name of the upstream package right now).
>
> As Fedora should match the upstream naming, I believe this change is necessary.
>
> Another naming change is required for the "minizip-compat" package which is the 
> subpackage of the "zlib" package. Upstream requests that we should rename 
> "minizip-compat" to "minizip".
>
> I agree with renaming this package as well, however, this could lead to multiple 
> confusions maybe even conflicts for the users. The problem with renaming this package 
> right after renaming the "minizip-ng" could be that the users may be confused about 
> which package is the right "minizip" for them.
>
> I believe we could rename the "minizip-compat" to the "minizip" after some larger time 
> period so every package that requires "minizip" changes the requirements to "minizip-ng" 
> and there is no confusion anymore.
>
> The first step I want to do is to create a Fedora Change, which contains this whole 
> process and is well communicated within the community.
>
> This email serves as a heads-up and also opens a possibility for any tips that you can 
> give me with this change. This is my first time doing a change like this so it may have 
> some bumps along the way, but I'm willing to learn and improve, so feel free to give me 
> any advice you think could benefit me with this process.
>
> Thank you for understanding and sorry for quite a long email.
> Lukas
> -- 
> 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
>
> [e-mail]
>
> https://www.redhat.com
>
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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 on the list, report it: https://pagure.io/fedora-infrastructure

[Daniel P. Berrangé]

On Thu, Jul 28, 2022 at 10:44:14AM +0200, Marcus Müller wrote:
> The latter change seems unwise. Packages which now depend on minizip (to be
> minizip-ng) will continue to do depend on whatever Provides(minizip); if you
> rename the zlib subpackage to minizip, they will depend on the wrong thing.

Both these packages merely provide an ELF library. As such anything that
depends on them should have automatically gained a Requires against the
SONAME of the contained library - 'libminizip.so.3.0()(64bit)' (for minizip)
vs 'libminizip.so.1()(64bit)' (for minizip-compat).

As such it shouldn't matter what the actual package name is, any dep will
continue to resolve to the correct renamed package at install time.

The only significant impact of the rename should be on BuildRequires
which could end up pulling in the wrong version, but presumably if
the API is different that ought to resolve in a koji build failure
which is easy enough to identify and fix the BuildRequires.

With regards,
Daniel

[Marcus Müller]

ah, true, different sonames solves this :)

On 28.07.22 10:52, Daniel P. Berrangé wrote:
> On Thu, Jul 28, 2022 at 10:44:14AM +0200, Marcus Müller wrote:
> > The latter change seems unwise. Packages which now depend on minizip (to be
> > minizip-ng) will continue to do depend on whatever Provides(minizip); if you
> > rename the zlib subpackage to minizip, they will depend on the wrong thing.
>
> Both these packages merely provide an ELF library. As such anything that
> depends on them should have automatically gained a Requires against the
> SONAME of the contained library - 'libminizip.so.3.0()(64bit)' (for minizip)
> vs 'libminizip.so.1()(64bit)' (for minizip-compat).
>
> As such it shouldn't matter what the actual package name is, any dep will
> continue to resolve to the correct renamed package at install time.
>
> The only significant impact of the rename should be on BuildRequires
> which could end up pulling in the wrong version, but presumably if
> the API is different that ought to resolve in a koji build failure
> which is easy enough to identify and fix the BuildRequires.
>
> With regards,
> Daniel

[Lukas Javorsky]

Also, the idea is to file Bugs for all packages that BuildRequire/Require
the minizip package and let them know about this change and if they should
change theirs requirements.

On Thu, Jul 28, 2022 at 10:57 AM Marcus Müller  wrote:
> ah, true, different sonames solves this :)
>
> On 28.07.22 10:52, Daniel P. Berrangé wrote:
> > On Thu, Jul 28, 2022 at 10:44:14AM +0200, Marcus Müller wrote:
> > > The latter change seems unwise. Packages which now depend on minizip
>
> (to be
> > > minizip-ng) will continue to do depend on whatever Provides(minizip);
>
> if you
> > > rename the zlib subpackage to minizip, they will depend on the wrong
>
> thing.
> > Both these packages merely provide an ELF library. As such anything that
> > depends on them should have automatically gained a Requires against the
> > SONAME of the contained library - 'libminizip.so.3.0()(64bit)' (for
>
> minizip)
> > vs 'libminizip.so.1()(64bit)' (for minizip-compat).
> >
> > As such it shouldn't matter what the actual package name is, any dep will
> > continue to resolve to the correct renamed package at install time.
> >
> > The only significant impact of the rename should be on BuildRequires
> > which could end up pulling in the wrong version, but presumably if
> > the API is different that ought to resolve in a koji build failure
> > which is easy enough to identify and fix the BuildRequires.
> >
> > With regards,
> > Daniel
>
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure

[Lukas Javorsky]

I've checked the packaging that should be affected by this change on Fedora
Rawhide:
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

On Thu, Jul 28, 2022 at 11:18 AM Lukas Javorsky  wrote:
> Also, the idea is to file Bugs for all packages that BuildRequire/Require
> the minizip package and let them know about this change and if they should
> change theirs requirements.
>
> On Thu, Jul 28, 2022 at 10:57 AM Marcus Müller  wrote:
> > ah, true, different sonames solves this :)
> >
> > On 28.07.22 10:52, Daniel P. Berrangé wrote:
> > > On Thu, Jul 28, 2022 at 10:44:14AM +0200, Marcus Müller wrote:
> > > > The latter change seems unwise. Packages which now depend on minizip
> >
> > (to be
> > > > minizip-ng) will continue to do depend on whatever Provides(minizip);
> >
> > if you
> > > > rename the zlib subpackage to minizip, they will depend on the wrong
> >
> > thing.
> > > Both these packages merely provide an ELF library. As such anything that
> > > depends on them should have automatically gained a Requires against the
> > > SONAME of the contained library - 'libminizip.so.3.0()(64bit)' (for
> >
> > minizip)
> > > vs 'libminizip.so.1()(64bit)' (for minizip-compat).
> > >
> > > As such it shouldn't matter what the actual package name is, any dep
> >
> > will
> > > continue to resolve to the correct renamed package at install time.
> > >
> > > The only significant impact of the rename should be on BuildRequires
> > > which could end up pulling in the wrong version, but presumably if
> > > the API is different that ought to resolve in a koji build failure
> > > which is easy enough to identify and fix the BuildRequires.
> > >
> > > With regards,
> > > Daniel
> >
> > devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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 on the list, report it:
> > https://pagure.io/fedora-infrastructure
>
> --
> 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
>
> [e-mail]
> https://www.redhat.com

[Fabio Valentini]

On Thu, Jul 28, 2022 at 11:19 AM Lukas Javorsky  wrote:
> Also, the idea is to file Bugs for all packages that BuildRequire/Require the minizip package and let them know about this change and if they should change theirs requirements.

Just an idea: You could even make the switch from minizip ->
minizip-ng a (partially) backwards-compatible change, by adding some
virtual provides (something like: add "Provides: minizip-ng" to
minizip, and "Provides: minizip-ng-devel" to minizip-devel), maybe
even in all current Fedora branches. That way, packages could start to
migrate, without needing conditionals in spec files for different
Fedora branches, and they'd be seamlessly switched over from minizip
to minizip-ng once the package is renamed.

Fabio

[Lukas Javorsky]

Hi,

I just got a question about how should I track the removal of "Provides and
Obsoletes" from the new minizip-ng package.

We've decided to remove them in Fedora 42, but it's impossible to remember
to do it for 2 years.
There is no way to file a Bugzilla to Fedora 42 yet.

Is there some place where I can track it and it will remind me to do it
when Fedora 42 is finally rawhide?

Thanks for suggestions
Lukas

On Fri, Jul 29, 2022 at 1:08 PM Fabio Valentini 
wrote:
> On Thu, Jul 28, 2022 at 11:19 AM Lukas Javorsky 
> wrote:
> > Also, the idea is to file Bugs for all packages that
>
> BuildRequire/Require the minizip package and let them know about this
> change and if they should change theirs requirements.
>
> Just an idea: You could even make the switch from minizip ->
> minizip-ng a (partially) backwards-compatible change, by adding some
> virtual provides (something like: add "Provides: minizip-ng" to
> minizip, and "Provides: minizip-ng-devel" to minizip-devel), maybe
> even in all current Fedora branches. That way, packages could start to
> migrate, without needing conditionals in spec files for different
> Fedora branches, and they'd be seamlessly switched over from minizip
> to minizip-ng once the package is renamed.
>
> Fabio
> _______________________________________________
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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 on the list, report it:
> https://pagure.io/fedora-infrastructure

[Dan Horák]

On Thu, 15 Sep 2022 13:10:41 +0200
Lukas Javorsky  wrote:
> Hi,
>
> I just got a question about how should I track the removal of "Provides and
> Obsoletes" from the new minizip-ng package.
>
> We've decided to remove them in Fedora 42, but it's impossible to remember
> to do it for 2 years.
> There is no way to file a Bugzilla to Fedora 42 yet.
>
> Is there some place where I can track it and it will remind me to do it
> when Fedora 42 is finally rawhide?

put a comment in the specfile :-)

Dan

[Lukas Javorsky]

> put a comment in the specfile :-)

That's quite easy to miss.

On Thu, Sep 15, 2022 at 1:38 PM Dan Horák  wrote:
> On Thu, 15 Sep 2022 13:10:41 +0200
> Lukas Javorsky  wrote:
> > Hi,
> >
> > I just got a question about how should I track the removal of "Provides
>
> and
> > Obsoletes" from the new minizip-ng package.
> >
> > We've decided to remove them in Fedora 42, but it's impossible to
>
> remember
> > to do it for 2 years.
> > There is no way to file a Bugzilla to Fedora 42 yet.
> >
> > Is there some place where I can track it and it will remind me to do it
> > when Fedora 42 is finally rawhide?
>
> put a comment in the specfile :-)
>             Dan
>
> devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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

[Zbigniew Jędrzejewski-Szmek]

On Fri, Sep 16, 2022 at 09:48:28AM +0200, Lukas Javorsky wrote:
> > put a comment in the specfile :-)
>
> That's quite easy to miss.

It's also no problem if the Obsoletes/Provides remain in place. Even
indefinitely. A comment in the spec file is the correct mechanism for
this, as it's something that somebody should do at some unspecified
point in the time, maybe when doing a spec file cleanup for a new version.

Zbyszek

[Ben Cotton]

On Thu, Sep 15, 2022 at 7:11 AM Lukas Javorsky  wrote:
> We've decided to remove them in Fedora 42, but it's impossible to remember to do it for 2 years.
> There is no way to file a Bugzilla to Fedora 42 yet.

I can create a '42' version in Bugzilla and disable it after the bug
is created. I don't know if that would help the "remember" part, but
it would give you a way to track things. If you want to do that, email
me off list with the summary/comments you'd want to include.

[Ben Cotton]

On Thu, Jul 28, 2022 at 4:32 AM Lukas Javorsky  wrote:
> The first step I want to do is to create a Fedora Change, which contains this whole process and is well communicated within the community.
>
> This email serves as a heads-up and also opens a possibility for any tips that you can give me with this change. This is my first time doing a change like this so it may have some bumps along the way, but I'm willing to learn and improve, so feel free to give me any advice you think could benefit me with this process.

Great! If you haven't seen already, the process is documented at
https://docs.fedoraproject.org/en-US/program_management/changes_policy/

If you have any questions or see places where the docs are unclear,
please let me know. There's plenty of room for improvement.

[Lukas Javorsky]

I've just created a Fedora Change devoted for this:
https://fedoraproject.org/wiki/Changes/MinizipRenaming

Feel free to add some comments there.

On Thu, Jul 28, 2022 at 6:33 PM Ben Cotton  wrote:
> On Thu, Jul 28, 2022 at 4:32 AM Lukas Javorsky 
> wrote:
> > The first step I want to do is to create a Fedora Change, which contains
>
> this whole process and is well communicated within the community.
> > This email serves as a heads-up and also opens a possibility for any
>
> tips that you can give me with this change. This is my first time doing a
> change like this so it may have some bumps along the way, but I'm willing
> to learn and improve, so feel free to give me any advice you think could
> benefit me with this process.
>
> Great! If you haven't seen already, the process is documented at
> https://docs.fedoraproject.org/en-US/program_management/changes_policy/
>
> If you have any questions or see places where the docs are unclear,
> please let me know. There's plenty of room for improvement.
>
> --
> Ben Cotton
> He / Him / His
> Fedora Program Manager
> Red Hat
> TZ=America/Indiana/Indianapolis