https://bugzilla.redhat.com/show_bug.cgi?id=1970073 Fabio Valentini <decathorpe@xxxxxxxxx> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |decathorpe@xxxxxxxxx --- Comment #1 from Fabio Valentini <decathorpe@xxxxxxxxx> --- I don't have time to make a full review, but here's a few comments: 1) If the pypi archive does not contain a license file, you should ask upstream to ship one with the pypi archives. If you nicely point out to upstreams that the license text of their project specifies that the actual license text MUST be shipped with redistributed sources (like, uhm, sources published to PyPI 😅), they usually respond quickly and include files with those sources (for example, I asked another project to include an MIT license text in https://github.com/emilk/snake_case/issues/2 - it's a Rust project, but the gist is the same: add LICENSE file to repository - if it's not there already - and make sure it's included when publishing sources). 2) Obsoletes: python3-azure-sdk < 5.0.1 Conflicts: python3-azure-sdk Whether those take this form or not, those lines need to be moved to the python3-azure-core subpackage section, or they will have no effect whatsoever - since no "main" binary package with the name python-%{srcname} is built that they could apply to. If the new, "split" SDK is compatible with the old one, and occupies the same places in the filesystem, I would say that this is a case of the "renamed package" case of the packaging guidelines, but complicated by the fact that the new package is actually many packages 😓 See: https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages So, to be completely thorough and safe, I would add something like the following to *all* successor packages of python-azure-sdk: - In the main packages: Epoch: 1 - In the python3-%{srcname} subpackages: Obsoletes: python3-azure-sdk < 5.0.0-6 Provides: python3-azure-sdk = %{epoch}:%{version}-%{release} Those two lines will make sure that the entire split azure-sdk replacement gets installed on upgrade, and that the old monolithic package version is removed. If you really really don't want Epoch (it's necessary because new components have versions that are lower than 5.0.0), you *could* (I think) use conflicts instead of the Provides, but I would recommend not to do that, and avoid using Conflicts where they're not absolutely necessary. To explain the "< 5.0.0-6" part: It is computed from the EVR of the obsoleted package that was last available from Fedora. Right now, the EVR of python-azure-sdk in rawhide is: "5.0.0-5.fc35", so the obsoleted version is "< 5.0.0-6" (see "Take %{?dist} into account" CAUTION box in the Packaging Guidelines chapter on renaming packages). Hope that helps. -- 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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
