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
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
ljavorsk@redhat.com
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 on the list, report it: https://pagure.io/fedora-infrastructure
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
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
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 marcus@hostalia.de 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 -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
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 ljavorsk@redhat.com 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 marcus@hostalia.de 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 -- 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 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
ljavorsk@redhat.com https://www.redhat.com
On Thu, Jul 28, 2022 at 11:19 AM Lukas Javorsky ljavorsk@redhat.com 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
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 decathorpe@gmail.com wrote:
On Thu, Jul 28, 2022 at 11:19 AM Lukas Javorsky ljavorsk@redhat.com 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 -- 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 on the list, report it: https://pagure.io/fedora-infrastructure
On Thu, 15 Sep 2022 13:10:41 +0200 Lukas Javorsky ljavorsk@redhat.com 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
put a comment in the specfile :-)
That's quite easy to miss.
On Thu, Sep 15, 2022 at 1:38 PM Dan Horák dan@danny.cz wrote:
On Thu, 15 Sep 2022 13:10:41 +0200 Lukas Javorsky ljavorsk@redhat.com 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 -- 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
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
On Thu, Sep 15, 2022 at 7:11 AM Lukas Javorsky ljavorsk@redhat.com 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.
On Thu, Jul 28, 2022 at 4:32 AM Lukas Javorsky ljavorsk@redhat.com 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.
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 bcotton@redhat.com wrote:
On Thu, Jul 28, 2022 at 4:32 AM Lukas Javorsky ljavorsk@redhat.com 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
devel@lists.stg.fedoraproject.org
-
Ben Cotton -
Dan Horák -
Daniel P. Berrangé -
Fabio Valentini -
Lukas Javorsky -
Marcus Müller -
Zbigniew Jędrzejewski-Szmek