On Mon, 13 May 2019 at 14:08, Nico Kadel-Garcia <nkadel at gmail.com> wrote: > On Mon, May 13, 2019 at 8:41 AM Stephen John Smoogen <smooge at gmail.com> > wrote: > > > A system may have 3 pythons on it , and each one will look in different > places for libraries > > > > platform-python is a minimal python which is meant only for allowing > system packages to run. It will probably not see much updates over the life > of RHEL-8. This is based of off python-3.6 > > python2.7 which is the 2.7 version of python and I expect will have a > lifetime until RHEL-7 is end of lifed. At that point the module will > probably be ended. > > python3.6 which is the 3.6 module and may later be end of lifed and > replaced with python-<major>.<minor> of upstreams choosing. > > Begging your pardon, but so what if there are many distinct pythons > available? It this one is the system default python, great. But this > It matters because system-python is paired down to what is needed to run the things BaseOS comes with. It may not support much else... and most of the pythonX-FOOBAR packages will not be used by it or vice versa. > is making various existing tools incompatible, with this and other > "platform" packages. don't break the existing tools, especially Fedora > and backporting work from there to RHEL and CentOS. This renaming > particularly includes the CentOS 7 "extras" packages with "python" in > the name, all 76 of them. It's creating work. > > Hey.. I am just the messenger here. Shoot me all you want, but it doesn't change the fact that this is done and shipped by upstream. > I'm also afraid I don't see where the frequency of updates affects > this. This is partly because I think it's very optimistic to say that > python 3.6 won't get any incremental updates. It's already been > updated once since the original DVD medium was published for RHEL 8. > It's fairly common to do minor updates to tools like this during point > releases. > > I didn't mean they wouldn't get updates, I was trying to say that modules have a different lifetime cycle than the main release. RHEL-8 has a 10 year lifetime, but python36 may only have a 4 year lifetime (or it might have 8.. future is hazy). The idea is that if python38 or python4 or python52 come out during that 10 years.. RHEL-8 could ship a module set with it in them. > This "rename packages as platform-package" name seems confusing and > unnecessary. If that kind of reference to "platform" versions were > needed, perhaps it should have been published as a metapackage, with > "platform-python" empty except for "Includes: python3". As it is, it > seems merely confusing and in conflict with 20 years of Red Hat > package naming convention. > Again.. I am not disagreeing with you. As far as I can tell, we have to throw something major out every big release. For the last couple we completely threw out the init systems (systemV->upstart->systemd) and we finally stuck that one so naming conventions and sub-packaging are the new big thing. _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > -- Stephen J Smoogen. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20190513/aea14676/attachment-0008.html>