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 -- [email protected]
> To unsubscribe send an email to [email protected]
> 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/[email protected]
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
--
Sérgio M. B.
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
