On Fri, 2019-03-01 at 00:35 +0100, Miro Hrončok wrote: > > > > More generally, the *flood* of Python 2 dep issues here is something I > > > > was definitely concerned about with the Python 2 retirement policy > > > > explicitly deciding not to say anything about obsoleting Python 2 > > > > subpackages :( > > > > > > I wanted the py3 packages to obsolte the py2, but i was outvoted. > > > > > > I now manually add those to fedora-obsoelte-packages, but I do it in batches. > > > I wait for a compose now to make another batch (fora rawhide and f30). > > > > I think where the upgrade fails because the python2 package is a > > subpackage and has a version-specific dependency on another subpackage > > from the same source package, that other subpackage should obsolete it. > > > > That's what I did for blockdev: python2-blockdev requires libblockdev > > of the same version, so to me it makes sense for libblockdev to > > obsolete python2-blockdev in builds where python2-blockdev is not > > built: > > > > https://src.fedoraproject.org/rpms/libblockdev/c/46c87cc14b2e4783555221d49fbdff7138fb6c0f?branch=master > > > > do you see any issues with that? > > I don't. I completely agree with this approach. Cool. FWIW, reading the ticket you linked, *this* approach was not considered (only 'python3 package has obsoletes' versus 'fedora- obsolete-packages has obsoletes' scenarios seem to have been considered), so I'm going to consider that it's fine until someone tells me to stop. ;) > According to the package guidelines, you should stick with a hardcoded > version-release here. > However if you update the package in previous Fedoras, you need to raise the > hardcoded version. I consider that a great PITA. I do not see that anywhere in the guidelines. In fact there's an explicit example that uses *this* pattern in the guidelines: https://docs.fedoraproject.org/en-US/packaging-guidelines/#renaming-or-replacing-existing-packages Provides: oldpackagename = $provEVR Obsoletes: oldpackagename < $obsEVR OK, that's not the precise same situation, but it seems to establish a precedent that relative obsoletes are fine... > See the entire discussion in https://pagure.io/packaging-committee/issue/754 Thanks! I don't see any note here that any decision was actually made on the version question, though. The question was asked, but no resolution to it was reported back to the ticket AFAICS. Reading the meeting log, it seems like it's more of a policy of tibbs' that obsoletes in fedora-obsolete-packages should be versioned? Which is kind of a different thing. I haven't had any need to tell him he's wrong about that yet. ;) But of course, that's a drawback of f-o-p: you *can't* do something like "Obsoletes: python2-foo < %{version}- %{release}" in f-o-p. Another thing I note from the meeting log is that, AFAICS, no actual vote was ever taken on any policy or declaration. I don't think your comment on the issue - "The resolution from the meeting was the following: When removing py2 package, don't obsolete it from py3, but rather obsolete it from fedora-obsolete-packages but only if keeping that package installed is likely to cause problems on upgrades." - is actually *correct*. From the log, nothing like that text was ever actually proposed or voted on at all. The only quasi-formal outcome of the entire discussion was geppetto's: #info mhroncok to help tibbs co-maintain fedora-obsolete-packages #info We acknowledge that there are likely to be a lot of py2 packages added to fedora-obsolete-packages in the near future -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
