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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
