Spec URL: https://fedorapeople.org/~mhayden/python-azure-core.spec SRPM URL: https://fedorapeople.org/~mhayden/python-azure-core-1.14.0-1.fc35.src.rpm Description: Azure Core shared client library for Python Fedora Account System Username: mhayden This is part of the work needed to package the newer bits in the Azure SDK (see BZ 1953789) and eventually, the Azure CLI. Running tests within the package isn't possible yet because of circular dependencies within the Azure SDK. Some of the packages required for testing the SDK are dependent on packages which are part of the SDK itself. Please note that python-azure-sdk already exists in Fedora as version 5.0.0-x. Microsoft used to release their SDK as one big package with little components in it, but they've been releasing the components individually since January 2021. This is my first time working on a package that obsoletes/conflicts another package, so please let me know if I should be going about this a different way. 🤗
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.
Note: I am not 100% sure if adding the Provides for the old package name in *all* successor packages is the right thing to do. The Obsoletes should definetly be in all successors to make sure the upgrade works as expected, but the Provides could end up in only one of the new azure-core packages. In that case, only that one package would need an Epoch (to artificially bump its version above 5.0.0).
(In reply to Fabio Valentini from comment #2) > Note: I am not 100% sure if adding the Provides for the old package name in > *all* successor packages is the right thing to do. The Obsoletes should > definetly be in all successors to make sure the upgrade works as expected, > but the Provides could end up in only one of the new azure-core packages. In > that case, only that one package would need an Epoch (to artificially bump > its version above 5.0.0). The challenging part here is that we're going from one big package to lots of small packages which don't have a "main" package of any sort. Sure, python-azure-core and python-azure-common are the most basic dependencies of the whole Azure SDK, but there's no single main package. Does that change anything?
(In reply to Fabio Valentini from comment #1) > 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). Good point. I made a PR upstream[0] to correct these core 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} Thanks for the help in understanding that better. I've revised the spec/SRPMs found here: Spec URL: https://fedorapeople.org/~mhayden/python-azure-core.spec SRPM URL: https://fedorapeople.org/~mhayden/python-azure-core-1.14.0-1.fc35.src.rpm [0] https://github.com/Azure/azure-sdk-for-python/pull/19191
I went back and re-read Mohamed's comments from 1953789, and it might make sense to package all of these small components and then use python-azure-sdk as the metapackage that ties them all together. I don't entirely know how to make all of the versioning work along the way, but it feels like a better user experience in the end since the user can install python3-azure-sdk and get the components that they are accustomed to. I've revised the spec for python-azure-core and I've removed the Obsoletes/Provides portions. Spec URL: https://fedorapeople.org/~mhayden/python-azure-core.spec SRPM URL: https://fedorapeople.org/~mhayden/python-azure-core-1.14.0-1.fc35.src.rpm Koji scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=69736040
Upstream updated to 1.15.0. Spec URL: https://fedorapeople.org/~mhayden/python-azure-core.spec SRPM URL: https://fedorapeople.org/~mhayden/python-azure-core-1.15.0-1.fc35.src.rpm Koji scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=69800007
Spec URL: https://fedorapeople.org/~mhayden/python-azure-core.spec SRPM URL: https://fedorapeople.org/~mhayden/python-azure-core-1.15.0-1.fc35.src.rpm Revised to include the co-maintained azure directory.
- Why did you close https://github.com/Azure/azure-sdk-for-python/pull/19191 ? Package approved. Package Review ============== Legend: [x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated [ ] = Manual review needed ===== MUST items ===== Generic: [x]: Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [x]: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %license. [x]: License field in the package spec file matches the actual license. Note: Checking patched sources after %prep for licenses. Licenses found: "Unknown or generated", "*No copyright* Expat License", "Expat License". 20 files have unknown license. Detailed output of licensecheck in /home/bob/packaging/review/python-azure-core/review- python-azure-core/licensecheck.txt [x]: Package contains no bundled libraries without FPC exception. [x]: Changelog in prescribed format. [x]: Sources contain only permissible code or content. [-]: Package contains desktop file if it is a GUI application. [-]: Development files must be in a -devel package [x]: Package uses nothing in %doc for runtime. [x]: Package consistently uses macros (instead of hard-coded directory names). [x]: Package is named according to the Package Naming Guidelines. [x]: Package does not generate any conflict. [x]: Package obeys FHS, except libexecdir and /usr/target. [-]: If the package is a rename of another package, proper Obsoletes and Provides are present. [x]: Requires correct, justified where necessary. [x]: Spec file is legible and written in American English. [-]: Package contains systemd file(s) if in need. [x]: Package is not known to require an ExcludeArch tag. [-]: Large documentation must go in a -doc subpackage. Large could be size (~1MB) or number of files. Note: Documentation size is 20480 bytes in 1 files. [x]: Package complies to the Packaging Guidelines [x]: Package successfully compiles and builds into binary rpms on at least one supported primary architecture. [x]: Package installs properly. [x]: Rpmlint is run on all rpms the build produces. Note: No rpmlint messages. [x]: Package requires other packages for directories it uses. [x]: Package does not own files or directories owned by other packages. [x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT [x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the beginning of %install. [x]: Macros in Summary, %description expandable at SRPM build time. [x]: Dist tag is present. [x]: Package does not contain duplicates in %files. [x]: Permissions on files are set properly. [x]: Package use %makeinstall only when make install DESTDIR=... doesn't work. [x]: Package is named using only allowed ASCII characters. [x]: Package does not use a name that already exists. [x]: Package is not relocatable. [x]: Sources used to build the package match the upstream source, as provided in the spec URL. [x]: Spec file name must match the spec package %{name}, in the format %{name}.spec. [x]: File names are valid UTF-8. [x]: Packages must not store files under /srv, /opt or /usr/local Python: [x]: Python eggs must not download any dependencies during the build process. [x]: A package which is used by another package via an egg interface should provide egg info. [x]: Package meets the Packaging Guidelines::Python [x]: Package contains BR: python2-devel or python3-devel [x]: Packages MUST NOT have dependencies (either build-time or runtime) on packages named with the unversioned python- prefix unless no properly versioned package exists. Dependencies on Python packages instead MUST use names beginning with python2- or python3- as appropriate. [x]: Python packages must not contain %{pythonX_site(lib|arch)}/* in %files [x]: Binary eggs must be removed in %prep ===== SHOULD items ===== Generic: [!]: If the source package does not include license text(s) as a separate file from upstream, the packager SHOULD query upstream to include it. [x]: Final provides and requires are sane (see attachments). [?]: Package functions as described. [x]: Latest version is packaged. [x]: Package does not include license text files separate from upstream. [-]: Sources are verified with gpgverify first in %prep if upstream publishes signatures. Note: gpgverify is not used. [-]: Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [x]: Package should compile and build into binary rpms on all supported architectures. [-]: %check is present and all tests pass. [x]: Packages should try to preserve timestamps of original installed files. [x]: Reviewer should test that the package builds in mock. [x]: Buildroot is not present [x]: Package has no %clean section with rm -rf %{buildroot} (or $RPM_BUILD_ROOT) [x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin. [x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file [x]: Sources can be downloaded from URI in Source: tag [x]: SourceX is a working URL. [x]: Spec use %global instead of %define unless justified. ===== EXTRA items ===== Generic: [x]: Rpmlint is run on all installed packages. Note: There are rpmlint messages (see attachment). [x]: Spec file according to URL is the same as in SRPM. Rpmlint ------- Checking: python3-azure-core-1.15.0-1.fc35.noarch.rpm python-azure-core-1.15.0-1.fc35.src.rpm 2 packages and 0 specfiles checked; 0 errors, 0 warnings.
(In reply to Robert-André Mauchin 🐧 from comment #8) > - Why did you close > https://github.com/Azure/azure-sdk-for-python/pull/19191 ? I plan to submit a PR that covers all of the modules in that repo that are missing license files. > Package approved. Thanks. I have questions on how to get this done with python-azure-sdk, but I'll take that to the mailing list.
(fedscm-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/python-azure-core