https://bugzilla.redhat.com/show_bug.cgi?id=1982306 --- Comment #10 from Jakub Ruzicka <jakub.ruzicka@xxxxxx> --- (In reply to Neal Gompa from comment #6) > > It would live in a separate libyang1 Dist-Git repository. > > You can see how we did it for OpenSSL here with openssl1.1: > https://src.fedoraproject.org/rpms/openssl1.1 > > Compatibility packages are exempted from requiring review: > https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/ > #_package_review_process > > For the legacy libyang1 package, we do not need to ship the libyang-tools > package, since the tools provided > there would be the same as what libyang (upgraded to v2) would include. Thanks for clarification. That makes perfect sense in a case of forward compatible v1 -> v2 where previous packages requiring libyang (v1) would work with v2 but IIUC libyang v2 is a big overhaul that's closer to a new library. This would effectively break all depending packages on upgrade - thus the explicit libyang2 plan. libyang-tools need to be moved out of v1 package either way - good point. > Actually, if you take a look at the existing libyang spec file, it's already > in pretty decent shape: > https://src.fedoraproject.org/rpms/libyang/blob/rawhide/f/libyang.spec We probably should've used that as a base instead of the upstream .spec... Well, regardless, there are many differences for v2 including different requires, build options, no python bindings, and more... it really felt like packaging a different library. After dropping all unnecessary things with the help of upstream, only the new .spec remained. Thanks for input, Neal. I'll discuss this with upstream further before proceeding. I think both ways have their (dis)advantages so it boils down to real relation between v1 and v2 and the effects of potential upgrade for existing users of the package. -- 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
