https://bugzilla.redhat.com/show_bug.cgi?id=1970073
Fabio Valentini <decathorpe(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |decathorpe(a)gmail.com
--- Comment #1 from Fabio Valentini <decathorpe(a)gmail.com> ---
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-re...
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