On 6/14/21 8:30 AM, Miro Hrončok wrote:
Not sure what you mean by "supersede" in this context, but I assume it wouldn't.Let me break it down:Would the python3-azure-common package automatically replace python3-azure-sdk during upgrades? No.Would the python3-azure-common package implicitly conflict with python3-azure-sdk? Possibly, if they install to overlapping locations on the filesystem.If a package (build)requires python3dist(azure-common) (or python3.Xdist(azure-common)), would it get python3-azure-common instead of python3-azure-sdk? Possibly, if python3-azure-sdk isn't pulled in by another requirement. The fact that "common" sorts earlier than "sdk" alphabetically plays in your favor :D
Oh wow, that's a lot to consider. Thanks for helping me understand that.
Here are my main questions: 1) How do I bring in these smaller packages carefully to avoid disruption?First of all, use a side tag: https://fedoraproject.org/wiki/Package_update_HOWTO#Multiple_Packages
I'll read up on that. Thank you.
Also, make sure to test the upgrade path. E.g. by: I. Installing the existing package versions on Fedora rawhide. II. Adding your copr repo.III. Testing `dnf upgrade` and also testing `dnf upgrade <individual_package>`
I have a small shell script that has been doing this for me in a rawhide container with podman.
When in trouble, add explicit Conflicts and/or Obsoletes as needed. If you share the error you get in (III.), I can help with this step.2) How do I convert the python-azure-sdk package into a no-files metapackage that brings in all of the SDK components?I. Bump the metadata to a newer version-release (artificial?). II. Remove all sources and contents of %prep/%build/%install. III. Remove all listed %files but keep the %files section. IV. Adapt other metdata like description, summary etc. V. Add the requirements that brings in all of the SDK components.VI. Use `%py_provides python3-azure-sdk` in the python3-azure-sdk package, as this is required for Python meta-packages without files.
This makes sense. Can I ping you when/if I have a PR ready in pagure to ensure I'm making good choices? 😉
(Is this even a good idea?)That depends. Would the users still want to `dnf install python3-azure-sdk`? If no, I would rather retire and obsolete the package from the relevant replacements. If you Obsolete a package from N other packages, they replace the obsoleted package during upgrade (all of them).
There's one other package that depends on the python3-azure-sdk package, but that's it. I'll go review its dependencies to see exactly what it is pulling in.
3) How should I go about getting these smaller packages reviewed?The majority of them are almost identical.I'd proceed normally, unless it's hundreds or thousands. How many reviews do you need? We can organize a sprint :)
There are about 80-90 packages last time I looked. Some have dependencies, so I've been getting the initial base ones reviewed first.
Thank you! -- Major Hayden
Attachment:
OpenPGP_0x737051E0C1011FB1.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
