https://bugzilla.redhat.com/show_bug.cgi?id=1913870 --- Comment #4 from code@xxxxxxxxxxxxxxxxxx --- > As for src/3rdParty/ - there are parts of old, forgotten projects compiled-in statically. > And I think there is no sense to package them separately. You still need to follow the guidelines in https://docs.fedoraproject.org/en-US/packaging-guidelines/#bundling, regardless of the age, upstream support, or popularity of the bundled dependencies. 1. If upstream allows building against an external library without patching, you MUST do so. That means you MUST package them separately, however inconvenient that may be. I’m not intimately familiar with the Qt build system, but it looks like that is not the case. 2. If upstream does not allow building against an external library without patching, people often try to develop a patch, since bundled libraries still have disadvantages (https://fedoraproject.org/wiki/Bundled_Libraries?rd=Packaging:Bundled_Libraries). You have made a reasonable argument against putting much effort into that. Again, I’m not intimately familiar with the Qt build system, but it looks like a patch would probably be nearly trivial, as the config files are simple text files and there are already examples of using external libraries. 3. If upstream does not allow building against an external library without patching, then you can choose to bundle. This is what you say you would prefer. In addition to dealing with the bundled library licenses, you must add virtual Provides with appropriate names and, if possible, versions, for all bundled libraries; you must publicly contact upstream about a path to supporting system libraries (see https://github.com/ArsMasiuk/qvge/issues/109, about Boost, which used to be bundled); and if upstream refuses, you must record it in a comment or in a source file referenced from a comment adjacent to the virtual Provides. All of these are MUST, not SHOULD. For the exact requirements, read the linked guidelines page. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx
