On 3 July 2017 at 02:04, Stephen John Smoogen <smooge@xxxxxxxxx> wrote: > On 1 July 2017 at 21:42, Nick Coghlan <ncoghlan@xxxxxxxxx> wrote: >> On 1 July 2017 at 03:36, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> wrote: >>> On Fri, 2017-06-30 at 12:07 +1000, Nick Coghlan wrote: >>>> Even if a 4.0 does happen, the magnitude of the change relative to the >>>> preceding 3.x release is expected to be comparable to that between any >>>> given 3.x and 3.x+1 release, so it wouldn't require the parallel stack >>>> approach that has proven necessary to handle the core data model >>>> changes that impacted the 2->3 transition. >>> >>> I thought it would be tolerably obvious that I didn't mean "literally >>> the specific conceptual Python 4.0 that at one point was expected to >>> exist after 3.9" or "any specific Python 4 release that happens". >>> Clearly what I meant was "any future non-backwards-compatible major >>> Python release". Maybe *right now* you don't expect there to be one, >>> but I'm sure there was probably a point during Python 1's lifetime at >>> which no-one expected there to be a backwards-incompatible Python 2, >>> and a point during Python 2's lifetime at which no-one expected there >>> to be a backwards-incompatible Python 3... >> >> No, as in the process of maintaining Python 2 & 3 in parallel for over >> a decade, we've significantly improved our toolset for *not* painting >> ourselves into similar corners in the future (and we're likely to >> introduce even more technical capabilities along those lines over >> time, such as Victor Stinner's proposal for a more flexible runtime >> code transformation pipeline). >> >> Now, obviously, we can't *stop* redistributor communities like Fedora >> from collectively declaring those process, policy, and technology >> changes ineffective, and instead investing their time and energy in >> planning for future disruptions that probably aren't going to happen. >> However, we *can* provide the advice that we don't believe such >> endeavours are going to represent a good use of that time and energy. >> > > OK here is the problem with this whole conversation in a nutshell. > Each side thinks the other one is bikeshedding and stopped listening > to the other. Thanks for the excellent summary of the situation Stephen. I'm not going to respond point by point, but instead use your post as a launching point for an arguably radical notion: we could explicitly explore supporting "late binding" of RPM dependency declarations in order to better support the folks that need old pieces of software to "just work" when built or run on a newer system, but are also prepared to keep all the pieces if they end up breaking that system in the process. > Here is the distributor problem in a nutshell. You will have people > come in who are not part of the the upstream community who just want > to get some old code they have working. They follow some old written > down instructions and find that boom instead of a working thing they > now have a broken pile of bolts with no idea why. Jason's offer to go backfill EPEL with "python2-*" metapackages prompted a question I hadn't really thought about before: what if we had a way to effectively generate additional virtual-provides at *installation time*, rather than all such declarations having to be baked directly into the RPMs at build time? That is, suppose we *never* added back build-time virtual provides for the "python-*" names, and instead added a new config file inside a new config directory "/etc/yum/aliases.d/" that said "If 'python-(.*)' isn't found, check for 'python3-\1' instead". DNF would then automatically convert any given name translation rules into the appropriate "OR" clauses in the rich dependency system. The net effect of this would be that, *by default*, unqualified "python-*" references would resolve to python3-*, just as they would if we updated the %python_provides macro. However, the big difference is that an end user could, if they wanted to, adjust their build environment (e.g. in a mock chroot) such that unqualified "python-*" references resolved to "python2-*" instead. That's something they can't readily do when the aliases are defined in the built RPMs - instead, you have to rebuild the world just to switch some aliases around. Such a system may even have more potential uses than just assisting with the Python 3 migration. For example: - install-time name translations between different distros (Py2 vs Py3 being just one example) - working around missing virtual provides in pre-built RPMs (e.g. missing "distXY(upstream-name)" metadata) - potentially making it easier to derive parallel-installable SCLs from mutually-exclusive modules So while I freely admit the idea is entirely speculative handwaving at this point, it seems to me like an approach that could even be integrated into the xdg-alternatives system (such that runtime switching can have complementary changes to install-time aliases), whereas anything we do purely at build-time is inherently inflexible from an end user's perspective. Regards, Nick. -- Nick Coghlan | ncoghlan@xxxxxxxxx | Brisbane, Australia _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
