https://bugzilla.redhat.com/show_bug.cgi?id=1970619 --- Comment #8 from Ben Beasley <code@xxxxxxxxxxxxxxxxxx> --- > (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. -- 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
