https://bugzilla.redhat.com/show_bug.cgi?id=2040624 --- Comment #9 from Ben Beasley <code@xxxxxxxxxxxxxxxxxx> --- (In reply to Kalev Lember from comment #8) > Oh, that's true, and it's actually installed as well, I think -- I totally > missed it at first because the python library must be hidden behind %files > -n python3-psautohint -f %{pyproject_files} and not explicitly listed in > %files. > > Anyway, maybe in that case it would make sense to have a split where: > > Source package name: psautohint > > Two binary packages: > psautohint (/usr/bin/*) > python3-psautohint (python library) This is good advice in general (especially coming from a C/C++ perspective) but I am not sure if it is worth separating them in this case. The implementations of the binaries live within the library and the actual scripts are trivial generated entry points of only a few lines each. There is little to be saved by not installing them when only the library is required. I suppose one could %exclude the __main__.py file from the library and package it with the binaries. That’s probably the right way to separate the two, but I don’t know if it would be worth it; that file is only ~30kB. It’s pretty common for primarily-application Python packages to also provide a Python library. The Provides like “python3dist(psautohint)” are generated automatically (assuming proper dist-info metadata), and the rest can be handled by adding an explicit “%py_provides python3-psautohint” if there is not an explicit library subpackage. It’s also pretty common for primarily-library Python packages to provide executable entry points without a separate subpackage—usually without a virtual Provides for the equivalent application name, although I don’t believe it would be incorrect to add one in cases where it’s clear what that name would be. Obviously, the dividing line between these two types of packages is fuzzy and subjective. There are plenty of cases where there doesn’t seem to be one clearly-correct answer, and there are plenty of examples of important existing packages that probably should have chosen the other naming scheme. -- 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 https://bugzilla.redhat.com/show_bug.cgi?id=2040624 _______________________________________________ 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
