I've noticed a few things that may help other people setting up test environments.
1) The RPMs on the installation media are split into two distinct repositories, "BaseOS" and "AppStream", for no reason I can discern. This means that if you try, like me, to mount a DVD image and use it as local yum repo for testing out kickstart setups and mock builds, you need to address the multiple necessary repositories with the new names.
2) For Virtualbox, it absolutely needs more than 1 GB of RAM.With only 1 GB, it hands during hte firstboot setups.
3) Mock is going to be.... awkward to port, due to multiple python dependencies in on the DVD.
On Thu, May 9, 2019 at 3:54 PM Nico Kadel-Garcia nkadel@gmail.com wrote:
I've noticed a few things that may help other people setting up test environments.
- The RPMs on the installation media are split into two distinct
repositories, "BaseOS" and "AppStream", for no reason I can discern. This means that if you try, like me, to mount a DVD image and use it as local yum repo for testing out kickstart setups and mock builds, you need to address the multiple necessary repositories with the new names.
- For Virtualbox, it absolutely needs more than 1 GB of RAM.With only
1 GB, it hands during hte firstboot setups.
- Mock is going to be.... awkward to port, due to multiple python
dependencies in on the DVD.
Sorry, got interrupted. That should read "due to multiple python dependencies for modules not found on the DVD.
On Thu, 9 May 2019 at 15:54, Nico Kadel-Garcia nkadel@gmail.com wrote:
I've noticed a few things that may help other people setting up test environments.
- The RPMs on the installation media are split into two distinct
repositories, "BaseOS" and "AppStream", for no reason I can discern. This means that if you try, like me, to mount a DVD image and use it as local yum repo for testing out kickstart setups and mock builds, you need to address the multiple necessary repositories with the new names.
So going from what was listed at Summit presentations: BaseOS is going to be packages which will not be updated majorly during the lifetime of the release. Appstream is going to be packages which may get updated often during the release. Something like Slow, Fast, Modules would probably have been more intuitive for us gear-heads but for most tech support probably not.
As you say, you will need to update kickstarts to add an additional repository.
- For Virtualbox, it absolutely needs more than 1 GB of RAM.With only
1 GB, it hands during hte firstboot setups.
I believe the recommended minimum is now 2GB. It can probably be done in less if you know what you are doing.
- Mock is going to be.... awkward to port, due to multiple python
dependencies in on the DVD.
Do you mean with using the system-python or using a python module?
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Thu, 9 May 2019 at 17:10, Stephen John Smoogen smooge@gmail.com wrote:
On Thu, 9 May 2019 at 15:54, Nico Kadel-Garcia nkadel@gmail.com wrote:
I've noticed a few things that may help other people setting up test environments.
- The RPMs on the installation media are split into two distinct
repositories, "BaseOS" and "AppStream", for no reason I can discern. This means that if you try, like me, to mount a DVD image and use it as local yum repo for testing out kickstart setups and mock builds, you need to address the multiple necessary repositories with the new names.
So going from what was listed at Summit presentations: BaseOS is going to be packages which will not be updated majorly during the lifetime of the release. Appstream is going to be packages which may get updated often during the release. Something like Slow, Fast, Modules would probably have been more intuitive for us gear-heads but for most tech support probably not.
As you say, you will need to update kickstarts to add an additional repository.
- For Virtualbox, it absolutely needs more than 1 GB of RAM.With only
1 GB, it hands during hte firstboot setups.
I believe the recommended minimum is now 2GB. It can probably be done in less if you know what you are doing.
- Mock is going to be.... awkward to port, due to multiple python
dependencies in on the DVD.
Do you mean with using the system-python or using a python module?
I believe for most compilations you need 1 more repository, Code Ready Linux Builder which contains a lot of the items you are looking for. With that enabled, you should be able to compile mock (at least my mockchain does not complain about missing packages).
On Thu, May 9, 2019 at 5:16 PM Stephen John Smoogen smooge@gmail.com wrote:
On Thu, 9 May 2019 at 17:10, Stephen John Smoogen smooge@gmail.com wrote:
On Thu, 9 May 2019 at 15:54, Nico Kadel-Garcia nkadel@gmail.com wrote:
I've noticed a few things that may help other people setting up test environments.
- The RPMs on the installation media are split into two distinct
repositories, "BaseOS" and "AppStream", for no reason I can discern. This means that if you try, like me, to mount a DVD image and use it as local yum repo for testing out kickstart setups and mock builds, you need to address the multiple necessary repositories with the new names.
So going from what was listed at Summit presentations: BaseOS is going to be packages which will not be updated majorly during the lifetime of the release. Appstream is going to be packages which may get updated often during the release. Something like Slow, Fast, Modules would probably have been more intuitive for us gear-heads but for most tech support probably not.
As you say, you will need to update kickstarts to add an additional repository.
- For Virtualbox, it absolutely needs more than 1 GB of RAM.With only
1 GB, it hands during hte firstboot setups.
I believe the recommended minimum is now 2GB. It can probably be done in less if you know what you are doing.
- Mock is going to be.... awkward to port, due to multiple python
dependencies in on the DVD.
Do you mean with using the system-python or using a python module?
I mean lots of modules, including pytest and python-setuptools_scm. It also lacks doxygen.
I believe for most compilations you need 1 more repository, Code Ready Linux Builder which contains a lot of the items you are looking for. With that enabled, you should be able to compile mock (at least my mockchain does not complain about missing packages).
Thank you for the pointer. I can believe that many such modules are in a distinct channel. It's certainly not on the installation DVD. The idea that "Code Ready Linux Builder" would contain various python modules, but that basic sofrtware building tools like gcc, make, and rpmbuild are om the basic AppStream channel seems..... well, it seems contradictory to me. I see that channel mentioned in plans for RHEL 8 at https://developers.redhat.com/blog/2018/11/15/introducing-codeready-linux-bu....
Is there any plan to support separating out this channel for CentOS? I hope it will be accessible by default in the base configurations, I really don't want to have deduce that my Chef configurations that need to compile small local tools need to also already be subscribed to such a separate channel.
On Thu, 9 May 2019 at 18:54, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Thu, May 9, 2019 at 5:16 PM Stephen John Smoogen smooge@gmail.com wrote:
- Mock is going to be.... awkward to port, due to multiple python
dependencies in on the DVD.
Do you mean with using the system-python or using a python module?
I mean lots of modules, including pytest and python-setuptools_scm. It also lacks doxygen.
Yeah it became clearer in your email I got after I sent this that you had dropped the explanation of what you meant.
I believe for most compilations you need 1 more repository, Code Ready
Linux Builder which contains a lot of the items you are looking for. With that enabled, you should be able to compile mock (at least my mockchain does not complain about missing packages).
Thank you for the pointer. I can believe that many such modules are in a distinct channel. It's certainly not on the installation DVD. The idea that "Code Ready Linux Builder" would contain various python modules, but that basic sofrtware building tools like gcc, make, and rpmbuild are om the basic AppStream channel seems..... well, it seems contradictory to me. I see that channel mentioned in plans for RHEL 8 at https://developers.redhat.com/blog/2018/11/15/introducing-codeready-linux-bu... .
Is there any plan to support separating out this channel for CentOS? I hope it will be accessible by default in the base configurations, I really don't want to have deduce that my Chef configurations that need to compile small local tools need to also already be subscribed to such a separate channel.
I do not know what the plans are for how things will be separated out yet. As you point out the split of things is rather... chaotic and could be prone to change upstream. I do not know if anything is pushed to CentOS which says where things go either.. so it will be later in the build/test/rc cycle before I think things will be known for sure.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Thu, 9 May 2019 at 19:08, Stephen John Smoogen smooge@gmail.com wrote:
On Thu, 9 May 2019 at 18:54, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Thu, May 9, 2019 at 5:16 PM Stephen John Smoogen smooge@gmail.com wrote:
- Mock is going to be.... awkward to port, due to multiple python
dependencies in on the DVD.
Do you mean with using the system-python or using a python module?
I mean lots of modules, including pytest and python-setuptools_scm. It also lacks doxygen.
Yeah it became clearer in your email I got after I sent this that you had dropped the explanation of what you meant.
I believe for most compilations you need 1 more repository, Code Ready
Linux Builder which contains a lot of the items you are looking for. With that enabled, you should be able to compile mock (at least my mockchain does not complain about missing packages).
Thank you for the pointer. I can believe that many such modules are in a distinct channel. It's certainly not on the installation DVD. The idea that "Code Ready Linux Builder" would contain various python modules, but that basic sofrtware building tools like gcc, make, and rpmbuild are om the basic AppStream channel seems..... well, it seems contradictory to me. I see that channel mentioned in plans for RHEL 8 at https://developers.redhat.com/blog/2018/11/15/introducing-codeready-linux-bu... .
Is there any plan to support separating out this channel for CentOS? I hope it will be accessible by default in the base configurations, I really don't want to have deduce that my Chef configurations that need to compile small local tools need to also already be subscribed to such a separate channel.
I do not know what the plans are for how things will be separated out yet. As you point out the split of things is rather... chaotic and could be prone to change upstream. I do not know if anything is pushed to CentOS which says where things go either.. so it will be later in the build/test/rc cycle before I think things will be known for sure.
Oh I was using the mock https://tdawson.fedorapeople.org/epel8/other/os/Packages/ to build my own things. The patches in his tree https://tdawson.fedorapeople.org/epel8/other/source/Packages/ may help you on your work.
On Thu, May 9, 2019 at 7:17 PM Stephen John Smoogen smooge@gmail.com wrote:
Oh I was using the mock https://tdawson.fedorapeople.org/epel8/other/os/Packages/ to build my own things. The patches in his tree https://tdawson.fedorapeople.org/epel8/other/source/Packages/ may help you on your work.
Thank you for this pointer. It's a good list of packages that I'd hoped would be built into RHEL 8, especially the "codeready-builder" channel when I heard about it. Barring that I hope will be quickly available in EPEL for use on both RHEL 8 and CentOS 8. Examples of the useful tools include mock itself and gpg-distribution-keys.
Good evening:
Even though Fedora still has a default /usr/bin/python, which has admittedly changed to a link to /usr/bin/python3 for recent releases, I see that RHEL 8 has no /usr/bin/python. This is going to break a *lot* SRPM's and older python scripts. It's especially going to mess up old "__python" configuration macros for .spec files.
I'd not realized this when I started testing. Heads up, a *lot* of EPEL .spec files are going to need updates.
Nico Kadel-Garcia nkadel@gmail.com
On 12/05/2019 04:45, Nico Kadel-Garcia wrote:
Good evening:
Even though Fedora still has a default /usr/bin/python, which has admittedly changed to a link to /usr/bin/python3 for recent releases, I see that RHEL 8 has no /usr/bin/python. This is going to break a *lot* SRPM's and older python scripts. It's especially going to mess up old "__python" configuration macros for .spec files.
I'd not realized this when I started testing. Heads up, a *lot* of EPEL .spec files are going to need updates.
Correct, there is no default 'python' in RHEL8 - you have python2 and python3, and you get to decide which you wish to use. This is well documented and there have been a lot of RH articles and blog postings about it. See for example:
https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/
If you are packaging software, you will need to decide if you wish to build against python2, python3 or both (that's going to be fun) and specify that explicitly. For example, we needed to patch the mock SPEC file when porting the latest version of mock from fedora to RHEL8 to explicitly specify python2 and/or python3.
The good news is the errors are pretty obvious:
*** ERROR: ambiguous python shebang in /usr/libexec/mock/mock: #!/usr/bin/python -tt. Change it to python3 (or python2) explicitly. *** ERROR: ambiguous python shebang in /usr/bin/mockchain: #!/usr/bin/python -tt.
and was easily fixed by explicitly specifying python2 instead of python in the code segment below:
%setup -q %if %{use_python2} for file in py/mock.py py/mockchain.py; do sed -i 1"s|#!/usr/bin/python3 |#!/usr/bin/python |" $file done %endif
On Sun, May 12, 2019 at 5:02 AM Phil Perry pperry@elrepo.org wrote:
On 12/05/2019 04:45, Nico Kadel-Garcia wrote:
Good evening:
Even though Fedora still has a default /usr/bin/python, which has admittedly changed to a link to /usr/bin/python3 for recent releases, I see that RHEL 8 has no /usr/bin/python. This is going to break a *lot* SRPM's and older python scripts. It's especially going to mess up old "__python" configuration macros for .spec files.
I'd not realized this when I started testing. Heads up, a *lot* of EPEL .spec files are going to need updates.
Correct, there is no default 'python' in RHEL8 - you have python2 and python3, and you get to decide which you wish to use. This is well documented and there have been a lot of RH articles and blog postings about it. See for example:
https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/
Right. There are many SRPMs in various repositories, especially EPEL and Fedora, that explicitly use '%{__python}' or /usr/bin/python in their .spec files, and many scripts that use "#!/usr/bin/env python". They all have to be updated. Evaluating RHEL 8
And sorry if this makes me seem a bit lame, but I've only just started testing RHEL 8 in force. I've not tried to catch up on all the blogs.
If you are packaging software, you will need to decide if you wish to build against python2, python3 or both (that's going to be fun) and specify that explicitly. For example, we needed to patch the mock SPEC file when porting the latest version of mock from fedora to RHEL8 to explicitly specify python2 and/or python3.
Yeah, I took a shot at building mock before I was pointed to https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/, which is very useful indeed. I also went through a lot of this when I backported awscli to RHEL 6 over at https://github.com/nkadel/awsclirepo . I was just noticing this on RHEL 8 as I tried to port awscli.
I'm sad to say that there are was also a confusing decision to rename some packages such as "platform-python-coverage" instead of the old name "python3-coverage", matching the python2-coverage which still exists. I've no idea why someone specifically chose to violate that naming convention, and it had to be a conscious choice.
The good news is the errors are pretty obvious:
Yeah, I've been running into this with RHEL 6 and CentOS 6 backports and on Fedora 30 where /usr/bin/python points to /usr/bin/python3. The errors are usually obvious, they just take time to fix and resolve. It *does* make me encourage the us of both "with_python2" and "with_python3" as options, so that which modules an SRPM is building can be explicit and help us migrate python2 packages to python3 in parallel, and safely.
I'm sad to say that there are was also a confusing decision to rename some packages such as "platform-python-coverage" instead of the old name "python3-coverage", matching the python2-coverage which still exists. I've no idea why someone specifically chose to violate that naming convention, and it had to be a conscious choice.
Be aware that there is a minimal python installation (called platform-python) that is used for platfrom/system tools like yum.
But this minimal python installation should not be used for anything else and thus there will likely be other packages with python{2,3}-* naming, as the platform-python-coverage will not be usable for the regular python installations.
At least this is how I understood the split from the blog posts.
best
~pete
On Sun, 12 May 2019 at 05:53, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Sun, May 12, 2019 at 5:02 AM Phil Perry pperry@elrepo.org wrote:
On 12/05/2019 04:45, Nico Kadel-Garcia wrote:
Good evening:
If you are packaging software, you will need to decide if you wish to
build against python2, python3 or both (that's going to be fun) and specify that explicitly. For example, we needed to patch the mock SPEC file when porting the latest version of mock from fedora to RHEL8 to explicitly specify python2 and/or python3.
Yeah, I took a shot at building mock before I was pointed to https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8/, which is very useful indeed. I also went through a lot of this when I backported awscli to RHEL 6 over at https://github.com/nkadel/awsclirepo . I was just noticing this on RHEL 8 as I tried to port awscli.
I'm sad to say that there are was also a confusing decision to rename some packages such as "platform-python-coverage" instead of the old name "python3-coverage", matching the python2-coverage which still exists. I've no idea why someone specifically chose to violate that naming convention, and it had to be a conscious choice.
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.
The good news is the errors are pretty obvious:
Yeah, I've been running into this with RHEL 6 and CentOS 6 backports and on Fedora 30 where /usr/bin/python points to /usr/bin/python3. The errors are usually obvious, they just take time to fix and resolve. It *does* make me encourage the us of both "with_python2" and "with_python3" as options, so that which modules an SRPM is building can be explicit and help us migrate python2 packages to python3 in parallel, and safely.
The errors are mostly obvious. There are a bunch of packages which have some /usr/bin/python embedded in it and may or may not be found during a build . [I think in most cases it will be found and error out, but I think I saw one where the python script was skipped and only showed up when I used it to build something else.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Mon, May 13, 2019 at 8:41 AM Stephen John Smoogen smooge@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 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.
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.
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.
On Mon, 13 May 2019 at 14:08, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Mon, May 13, 2019 at 8:41 AM Stephen John Smoogen smooge@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@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Mon, May 13, 2019 at 02:07:42PM -0400, Nico Kadel-Garcia wrote:
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.
The idea is that you never use the platform-package python at all. It's part of the OS, used for internal tools like dnf, and not in the standard path.
This will stop people from trying to use pip to upgrade the python modules used to run the package manager and break updates, for example.
For packages any other package, you'd use the appstream pythons in your dependencies. Its best you just treat the internal python as a black box and not something you actually package against.
On Mon, May 13, 2019 at 3:54 PM Jonathan Billings billings@negate.org wrote:
On Mon, May 13, 2019 at 02:07:42PM -0400, Nico Kadel-Garcia wrote:
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.
The idea is that you never use the platform-package python at all. It's part of the OS, used for internal tools like dnf, and not in the standard path.
I see your point. I also realize I'm late to the party, and this is already a done deal.
Unfortunately, they're not reliably distinct from the mainline python. Packages such as "platform-python-coverage" deposit their contents in /usr/lib64/python3.6/site-packages/coverage/. They do use "%python_provide" in their .spec file, so they get a stack of "Provides: python3dist(coverage)" and similar results. But this is not backwards compatible to older RHEL releases. And because the name of these "platform-party" packages does not even match the package name of the SRPM, well, it gets confusing to cross-index them. It could be really useful if the SRPM for python-coverage, which provided the default version of the coverage module, would add this line:
Provides: python%{python3_pkgversion}-coverage
This would be more consistent with the older package naming schemes, and more backwards compatible. I'd welcome thoughts as to whether this is a good idea to encourage from our upstream python packages for these "platform" components.
python3-pip, and platform-party-pip, is even more hilarious. The actual pip modules are from platform-party-pip. The binaries in /usr/bin/ are from python3-pip.
This will stop people from trying to use pip to upgrade the python modules used to run the package manager and break updates, for example.
That is a distinct issue. I've personally encountered it in full destructive force. I've personally published.... 300 SRPMs for various public and private repos? All to avoid just the random update issues of pip. I used to do that for cpan published perl packages, too. But that is a very distinct issue. Since "pip-3 install" now puts the modules in /usr/local/lib/python3.6/, I think that this alternative and effective solution has already solved most of *that* problem. Would you agree that it has to do with the default python module installation locations, and segregating critical system python tools from looking in those locations rather than in the system default locations?
For packages any other package, you'd use the appstream pythons in your dependencies. Its best you just treat the internal python as a black box and not something you actually package against.
Except..... there is no "appstream" package for the python3-coverage module. And trying to build a python3-coverage module shows that it would conflict with the platform-party-coverage module.
Maybe I found the one really awkward module? It wouldn't be the first time I found the edge case early in testing.
On 5/12/19 2:53 AM, Nico Kadel-Garcia wrote:
Yeah, I've been running into this with RHEL 6 and CentOS 6 backports and on Fedora 30 where /usr/bin/python points to /usr/bin/python3. The
That should not be the case in Fedora as far as I know.
/usr/bin/python in fedora (29+) is owned by the python-unversioned-command package, which is a subpackage of python2 and points /usr/bin/python to python2.
kevin
On Mon, May 13, 2019 at 2:15 PM Kevin Fenzi kevin@scrye.com wrote:
On 5/12/19 2:53 AM, Nico Kadel-Garcia wrote:
Yeah, I've been running into this with RHEL 6 and CentOS 6 backports and on Fedora 30 where /usr/bin/python points to /usr/bin/python3. The
That should not be the case in Fedora as far as I know.
/usr/bin/python in fedora (29+) is owned by the python-unversioned-command package, which is a subpackage of python2 and points /usr/bin/python to python2.
kevin
You're right! I thought it had been changed, along the switch of so many packages to use python3 by default. But it's still python2, even in rawhide.
-
Jonathan Billings -
Kevin Fenzi -
Nico Kadel-Garcia -
Peter Meier -
Phil Perry -
Stephen John Smoogen