Spec URL: https://fedorapeople.org/~mhayden/python-azure-common.spec SRPM URL: https://fedorapeople.org/~mhayden/python-azure-common-1.1.27-1.fc35.src.rpm Description: Microsoft Azure Client Library for Python (Common) Fedora Account System Username: mhayden This library and python-azure-core (see bug 1970073) are the base libraries for the Azure SDK (which are required for packing the Azure CLI). There is no license file currently but I have asked upstream to provide one[0]. https://github.com/Azure/azure-sdk-for-python/pull/19191
What package owns %{python3_sitelib}/azure?
At the moment, none of them. Azure has some namespace packages but they aren't needed for Python 3.9. We could probably pick one of these packages to be the owner of that directory. The azure-common package is required by the most amount of SDK libraries, so we could have the base azure directory owned by this package. Would that work?
> The azure-common package is required by the most amount of SDK libraries, so we could have the base azure directory owned by this package. Would that work? It would work, although it seems like you would have to introduce some otherwise-unnecessary artificial dependencies on this package. One way to avoid pulling in the full contents of this (admittedly small package) to create a directory would be to create a -filesystem package; that seems overkill for only one directory. I think the approach of co-owning any namespace directories would work well here. That ought to just need this added: > # Co-owned namespace package directory > %dir %{python3_sitelib}/azure in the %files section of every package that installs something directly into the azure directory. ----- The packaging guidelines have more general information about directory ownership (https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directory_ownership, https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories/), and there was a discussion specifically about the nuances of Python namespace packages and directory ownership not too long ago (https://lists.fedoraproject.org/archives/list/packaging@lists.fedoraproject.org/thread/URH4A6JCZCYOFAFPDGCGOLO5YRGZLQYT/).
(In reply to Ben Beasley from comment #3) > One way to avoid pulling in the full contents of this (admittedly small > package) to create a directory would be to create a -filesystem package; > that seems overkill for only one directory. So Azure has some remnants in their SDK repository that are meant to do that for Python versions before 3.0: ➜ find . -name "*-nspkg" ./sdk/nspkg/azure-agrifood-nspkg ./sdk/nspkg/azure-ai-nspkg ./sdk/nspkg/azure-ai-translation-nspkg ./sdk/nspkg/azure-cognitiveservices-knowledge-nspkg ./sdk/nspkg/azure-cognitiveservices-language-nspkg ./sdk/nspkg/azure-cognitiveservices-nspkg ./sdk/nspkg/azure-cognitiveservices-search-nspkg ./sdk/nspkg/azure-cognitiveservices-vision-nspkg ./sdk/nspkg/azure-communication-nspkg ./sdk/nspkg/azure-data-nspkg ./sdk/nspkg/azure-digitaltwins-nspkg ./sdk/nspkg/azure-iot-nspkg ./sdk/nspkg/azure-keyvault-nspkg ./sdk/nspkg/azure-media-nspkg ./sdk/nspkg/azure-messaging-nspkg ./sdk/nspkg/azure-mgmt-datalake-nspkg ./sdk/nspkg/azure-mgmt-nspkg ./sdk/nspkg/azure-mixedreality-nspkg ./sdk/nspkg/azure-nspkg ./sdk/nspkg/azure-purview-nspkg ./sdk/nspkg/azure-search-nspkg ./sdk/nspkg/azure-security-nspkg ./sdk/nspkg/azure-storage-nspkg ./sdk/nspkg/azure-synapse-nspkg ./sdk/nspkg/azure-monitor-nspkg From what I can see in most of the requirements code, they don't use it much anymore. ":python_version<'3.0'": ['azure-mgmt-nspkg'], > I think the approach of co-owning any namespace directories would work well > here. That ought to just need this added: > > > # Co-owned namespace package directory > > %dir %{python3_sitelib}/azure > > in the %files section of every package that installs something directly into > the azure directory. This makes sense to me. There's going to be quite a few things that install into %{python3_sitelib}/azure/** and it's not a big deal to add that to each spec. I'll adjust it and submit a new spec.
Spec URL: https://fedorapeople.org/~mhayden/python-azure-common.spec SRPM URL: https://fedorapeople.org/~mhayden/python-azure-common-1.1.27-1.fc35.src.rpm Revised to add the co-owned azure namespace directory.
Great, thanks! I think the other missing piece for a reviewer is understanding how you plan to handle conflicts with python-azure-sdk while you are creating these fine-grained packages. That seemed like it was still an open question in https://bugzilla.redhat.com/show_bug.cgi?id=1953789.
(In reply to Ben Beasley from comment #6) > I think the other missing piece for a reviewer is understanding how you plan > to handle conflicts with python-azure-sdk while you are creating these > fine-grained packages. That seemed like it was still an open question in > https://bugzilla.redhat.com/show_bug.cgi?id=1953789. Originally, I thought the only path forward was to build all of these little components, obsolete the python-azure-sdk package, and then the little components would go on to live forever. Then I read a bunch of documentation, looked through more specs, and asked people a few more questions. Then I re-read Mohamed's comments in https://bugzilla.redhat.com/show_bug.cgi?id=1953789 and it all clicked. (I am a bit of a slow learner at times.) 😞 The python-azure-sdk package has lots of little "Provides:" added automatically for the Azure SDK components by the Python RPM macros. Since Azure stopped releasing all of the SDK components together in January 2021, the version numbers of all of the little components (in the automatic "Provides:") went stagnant. The little components kept releasing from the main repository and their version numbers increased. As an example, this review is for python-azure-common-1.1.27, but the python-azure-common from python-azure-sdk (in the automatic provides) is less than python-azure-common-1.1.27, so this package should supersede it if I understand everything correctly now. The goal is to keep python-azure-sdk as the thing that ties all of these little packages together so someone could install "the whole SDK" using just the python-azure-sdk package and it would bring in all of the small SDK dependencies, like this one. Does this plan make any sense? I'd like to accomplish this without "Obsoletes:" if possible, and people keep telling me it's definitely possible.
> (I am a bit of a slow learner at times.) 😞 Don’t worry about it. There’s a lot of detail involved, and I’m surely not tracking it all by paying casual attention. > Does this plan make any sense? I'd like to accomplish this without "Obsoletes:" if possible, and people keep telling me it's definitely possible. Overall, at a glance, it seems like it makes sense! But the little packages are still going to have file and directory ownership conflicts with the old python3-azure-sdk package in the interim. For example, if I run fedora-review on this package, I get: > [ ]: Package does not own files or directories owned by other packages. > Note: Dirs in package are owned also by: /usr/lib/python3.9/site- > packages/azure/common(python3-azure-sdk), /usr/lib/python3.9/site- > packages/azure/common/__pycache__(python3-azure-sdk), > /usr/lib/python3.9/site-packages/azure/profiles(python3-azure-sdk), > /usr/lib/python3.9/site- > packages/azure/profiles/__pycache__(python3-azure-sdk) So if you’re planning to update python-azure-sdk so it is a metapackage with a bunch of Requires and no %files, that seems like a reasonable explanation for how these conflicts will go away. However, usually these kinds of transitions are handled pretty quickly. Until you get all the new packages created and eliminate the %files content from python3-azure-sdk, anything depending on a few of the fine-grained dependencies could end up pulling in both new packages and the old SDK package, then failing to install due to file or directory conflicts. One option would be to refrain from building (or importing, lest they get caught up in some mass rebuild) new packages that conflict with the existing python3-azure-sdk package. Then when everything is ready, do the imports and build everything in a side tag. That would be very clean, but you would have to make sure it was easy for reviewers to handle the fact that you were submitting packages with dependencies not in Rawhide yet. Setting up a COPR and mentioning the --copr-build option to fedora-review (which I’ve personally never used) ought to suffice. Maybe there’s another option I’m missing; perhaps someone who has actually handled this kind of transition before would have more practical advice.
Okay, I'll get the specs cleaned up and get them co-existing in the same COPR. I've started that in COPR[0] but it needs to be cleaned up now that some prerequisites have been merged into Fedora. [0] https://copr.fedorainfracloud.org/coprs/mhayden/azure-cli/
Should you still keep: Obsoletes: python3-azure-sdk < 5.0.1 Conflicts: python3-azure-sdk or will you move it to the python-azure-sdk metapackage like you said in the -core bug?
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". 9 files have unknown license. Detailed output of licensecheck in /home/bob/packaging/review/python-azure-common/review- python-azure-common/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 10240 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-common-1.1.27-1.fc35.noarch.rpm python-azure-common-1.1.27-1.fc35.src.rpm 2 packages and 0 specfiles checked; 0 errors, 0 warnings.
(In reply to Robert-André Mauchin 🐧 from comment #10) > Should you still keep: > > > Obsoletes: python3-azure-sdk < 5.0.1 > Conflicts: python3-azure-sdk > > > or will you move it to the python-azure-sdk metapackage like you said in the > -core bug? My current goal (sent a mail to the mailing list this morning) is to keep the python-azure-sdk package as a metapackage that someone can use to install all of the individual SDK components. Miro suggested building these small subcomponents into a side tag until everything is ready.
Linking your updated PR for including the license file upstream: https://github.com/Azure/azure-sdk-for-python/pull/19240
(In reply to Ben Beasley from comment #13) > Linking your updated PR for including the license file upstream: > https://github.com/Azure/azure-sdk-for-python/pull/19240 Thanks for doing that. That's one big PR! 🚚 Also, per the discussion and recommendation[0] from Miro, obsoleting python-azure-sdk seems like the lowest effort method for moving forward. I've tried to go about it so many different ways, but this seems the cleanest. [0] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/U73M3XLNGVKZ3D4DZ5ELKWDNBQ4W4F7X/
Spec URL: https://download.copr.fedorainfracloud.org/results/mhayden/azure-cli/fedora-rawhide-x86_64/02258303-python-azure-common/python-azure-common.spec SRPM URL: https://download.copr.fedorainfracloud.org/results/mhayden/azure-cli/fedora-rawhide-x86_64/02258303-python-azure-common/python-azure-common-1.1.27-1.fc35.src.rpm fedora-review output: https://copr-be.cloud.fedoraproject.org/results/mhayden/azure-cli/fedora-rawhide-x86_64/02258303-python-azure-common/fedora-review/review.txt Updated spec/SRPM using pyproject RPM macros.
Packqge approved.
(fedscm-admin): The Pagure repository was created at https://src.fedoraproject.org/rpms/python-azure-common