SHORT VERSION
The portmidi library in Fedora is at version 217, which is quite old. Upstream changed to a new version scheme, currently at 2.0.4, and dumped some subpackages. To serve the needs of different other packages, it would be easiest for me (as the portmidi maintainer in Fedora) and them to:
- create a new package portmidi2 - avoid any file conflicts between subpackages of portmidi and portmidi2 except: - allow file conflicts between portmidi{,2}-devel (.so, headers)
This would allow to build packages against both versions (just not in the same container) by simply requiring the right devel package, and the libraries could coexist. Is this allowed by the packaging guidelines?
LONG STORY
portmidi has been a slow moving package, with some code changes after the repo split and versioning change upstream. In Fedora land, I got several requests to update portmidi to 2.0.*, but:
- This requires epoch. - It is is not a strict update.
In particular, the python bindings are "gone" (separate unmaintained project) but are required by frescobaldi. Also, the java bindings were deprecated, then taken up again. We never shipped them in Fedora but used them to build portmidi-tools which no package requires. Several packages buildrequire portmidi: csound darktable denemo mame mscore prboom-plus pygame (I left out audacity and rpmfusion packages here.) All of them build fine against portmidi2:
https://copr.fedorainfracloud.org/coprs/mjg/portmidi2/
The failures are only on EPEL chroots, due to missing other BRs of those packages. portmidi2 builds there, and I got requests for EPEL, too.
I know that at least darktable maintainers would be happy about having the new features of portmidi2 specifically. The two usual alternatives are:
A) put up portmidi2 as an update to portmidi B) put up portmidi2 as a separate package, no conflicts
In A), it takes much longer to have portmidi2 available in released Fedoras. In particular, I would have to wait for python bindings or changes in frescobaldi.
In B) I would need to rename the library and the header install location. Not only is the upstream build process somewhat stubborn, but this could also require depending packages to adjust includes and such (unless everything is picked up from pkconf).
The suggestion under "SHORT VERSION" is a middle ground between A and B at the expense of conflicting devel packages.
https://src.fedoraproject.org/rpms/portmidi https://github.com/PortMidi/portmidi
I think so , see openssl example :
dnf install openssl1.1-devel openssl-devel
Package openssl-devel-1:3.0.8-1.fc37.x86_64 is already installed. Error: Problem: problem with installed package openssl-devel-1:3.0.8- 1.fc37.x86_64 - package openssl1.1-devel-1:1.1.1q-2.fc37.i686 conflicts with openssl- devel provided by openssl-devel-1:3.0.8-1.fc37.x86_64 - package openssl1.1-devel-1:1.1.1q-2.fc37.i686 conflicts with openssl- devel provided by openssl-devel-1:3.0.5-3.fc37.x86_64 - conflicting requests - package openssl1.1-devel-1:1.1.1q-2.fc37.x86_64 conflicts with openssl-devel provided by openssl-devel-1:3.0.8-1.fc37.x86_64 - package openssl1.1-devel-1:1.1.1q-2.fc37.x86_64 conflicts with openssl-devel provided by openssl-devel-1:3.0.5-3.fc37.x86_64
On Fri, 2023-03-03 at 19:00 +0100, Michael J Gruber wrote:
SHORT VERSION
The portmidi library in Fedora is at version 217, which is quite old. Upstream changed to a new version scheme, currently at 2.0.4, and dumped some subpackages. To serve the needs of different other packages, it would be easiest for me (as the portmidi maintainer in Fedora) and them to:
- create a new package portmidi2
- avoid any file conflicts between subpackages of portmidi and
portmidi2 except:
- allow file conflicts between portmidi{,2}-devel (.so, headers)
This would allow to build packages against both versions (just not in the same container) by simply requiring the right devel package, and the libraries could coexist. Is this allowed by the packaging guidelines?
LONG STORY
portmidi has been a slow moving package, with some code changes after the repo split and versioning change upstream. In Fedora land, I got several requests to update portmidi to 2.0.*, but:
- This requires epoch.
- It is is not a strict update.
In particular, the python bindings are "gone" (separate unmaintained project) but are required by frescobaldi. Also, the java bindings were deprecated, then taken up again. We never shipped them in Fedora but used them to build portmidi-tools which no package requires. Several packages buildrequire portmidi: csound darktable denemo mame mscore prboom-plus pygame (I left out audacity and rpmfusion packages here.) All of them build fine against portmidi2:
https://copr.fedorainfracloud.org/coprs/mjg/portmidi2/
The failures are only on EPEL chroots, due to missing other BRs of those packages. portmidi2 builds there, and I got requests for EPEL, too.
I know that at least darktable maintainers would be happy about having the new features of portmidi2 specifically. The two usual alternatives are:
A) put up portmidi2 as an update to portmidi B) put up portmidi2 as a separate package, no conflicts
In A), it takes much longer to have portmidi2 available in released Fedoras. In particular, I would have to wait for python bindings or changes in frescobaldi.
In B) I would need to rename the library and the header install location. Not only is the upstream build process somewhat stubborn, but this could also require depending packages to adjust includes and such (unless everything is picked up from pkconf).
The suggestion under "SHORT VERSION" is a middle ground between A and B at the expense of conflicting devel packages.
https://src.fedoraproject.org/rpms/portmidi https://github.com/PortMidi/portmidi _______________________________________________ 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
I think so , see openssl example :
dnf install openssl1.1-devel openssl-devel
Package openssl-devel-1:3.0.8-1.fc37.x86_64 is already installed. Error: Problem: problem with installed package openssl-devel-1:3.0.8- 1.fc37.x86_64
- package openssl1.1-devel-1:1.1.1q-2.fc37.i686 conflicts with openssl-
devel provided by openssl-devel-1:3.0.8-1.fc37.x86_64
- package openssl1.1-devel-1:1.1.1q-2.fc37.i686 conflicts with openssl-
devel provided by openssl-devel-1:3.0.5-3.fc37.x86_64
- conflicting requests
- package openssl1.1-devel-1:1.1.1q-2.fc37.x86_64 conflicts with
openssl-devel provided by openssl-devel-1:3.0.8-1.fc37.x86_64
- package openssl1.1-devel-1:1.1.1q-2.fc37.x86_64 conflicts with
openssl-devel provided by openssl-devel-1:3.0.5-3.fc37.x86_64
Thanks for pointing this out. Their compat had this in spec: ``` # The devel subpackage intentionally conflicts with main openssl-devel # as simultaneous use of both openssl package cannot be encouraged. # Making the packages non-conflicting would also require further # changes in the dependent packages. Conflicts: openssl-devel ``` I'm not sure this beats packaging guidelines, though ...
Il 03/03/23 19:00, Michael J Gruber ha scritto:
SHORT VERSION
The portmidi library in Fedora is at version 217, which is quite old. Upstream changed to a new version scheme, currently at 2.0.4, and dumped some subpackages. To serve the needs of different other packages, it would be easiest for me (as the portmidi maintainer in Fedora) and them to:
- create a new package portmidi2
- avoid any file conflicts between subpackages of portmidi and portmidi2 except:
- allow file conflicts between portmidi{,2}-devel (.so, headers)
This would allow to build packages against both versions (just not in the same container) by simply requiring the right devel package, and the libraries could coexist. Is this allowed by the packaging guidelines?
What about:
- create a compat-portmidi0 package and move current portmidi there (bonus: mark it as deprecated) - change frescobaldi to require the compat package until a fix is available - update current portmidi package to v2
BTW, this is not the first time such a discussion arise and I think FESCo / Packaging Guidelines must provide a definitive answer for this.
Mattia
Il 03/03/23 19:00, Michael J Gruber ha scritto: What about:
- create a compat-portmidi0 package and move current portmidi there
(bonus: mark it as deprecated)
- change frescobaldi to require the compat package until a fix is available
- update current portmidi package to v2
That is possible in the long term, anyway. But it takes time unless you do this on released Fedoras, too.
BTW, this is not the first time such a discussion arise and I think FESCo / Packaging Guidelines must provide a definitive answer for this.
Thanks to Sergio I know a precedent know. I'll take another look at pm2 to see if can somehow avoid the conflicts without creating hardships for depending packages, and otherwise go for the middleground plan which will require a review for te "new" package in any case.
On Sat, Mar 4, 2023 at 8:13 AM Michael J Gruber mjg@fedoraproject.org wrote:
Il 03/03/23 19:00, Michael J Gruber ha scritto: What about:
- create a compat-portmidi0 package and move current portmidi there
(bonus: mark it as deprecated)
- change frescobaldi to require the compat package until a fix is
available
- update current portmidi package to v2
That is possible in the long term, anyway. But it takes time unless you do this on released Fedoras, too.
Compatibility packages do not get a "compat-" prefix any more; they only get a version suffix. The old portmidi could be portmidi217 (to match the old versioning) or possibly portmidi0 (to match the soversion). It's also preferred (but I'm not sure that it's written down or is just a discussion within the FPC right now) that the un-suffixed version is the latest one. https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple
BTW, this is not the first time such a discussion arise and I think FESCo / Packaging Guidelines must provide a definitive answer for this.
Thanks to Sergio I know a precedent know. I'll take another look at pm2 to see if can somehow avoid the conflicts without creating hardships for depending packages, and otherwise go for the middleground plan which will require a review for te "new" package in any case.
Compatibility packages do not need a review. https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/#...
On Sat, Mar 4, 2023 at 8:13 AM Michael J Gruber <mjg(a)fedoraproject.org> wrote:
Compatibility packages do not get a "compat-" prefix any more; they only get a version suffix. The old portmidi could be portmidi217 (to match the old versioning) or possibly portmidi0 (to match the soversion). It's also preferred (but I'm not sure that it's written down or is just a discussion within the FPC right now) that the un-suffixed version is the latest one. https://docs.fedoraproject.org/en-US/packaging-guidelines/Naming/#multiple
Good point. Whether it's required or just preferred - it's a recommendation which I should follow, and why I've been asking here :)
It forces depending packages to choose between changing their BuildRequires (to the new name for the old version) or adjusting if needed (to the new version).
It also forces me to introduce epoch so that version 2.0.4 will be an update of the existing 217, right?
Now the big question is: In which releases can I rename the package? I'm afraid the answer will be "rawhide only", which means "new" portmidi will be in Fedora 39 only. Or can I have "portmidi0 + portmidi" there and "portmidi + portmidi2" in releases branches?
Compatibility packages do not need a review. https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuideline...
That much is clear. Your preference provides an answer to another question of mine: "... and MUST NOT conflict with all other versions of the same package." So, while openssl seems to violate that for whatever reasons, I cannot do the same.
So, technically speaking: - I go through the new-package process for a new package (the compat package) but note that no review is required. - Import the package (and history) into the newly created dist-git repo and rewrite the spec for the new name (portmidi0 or such). - Update the package in the old dist-git repo to the new repo.
Or do I request a new repo "portmidi2" and build the new "portmidi" from there ("and portmidi0" from the "portmidi" dist-git repo)?