Fedora is got a good choice if long term stability and usability is a high priority

December 11, 2019

Every so often I hear about people running servers or infrastructure that they care about on Fedora, and my eyebrows almost always go up. I like Fedora and run it by choice on all of my desktops and my work laptop, but I'm the sole user on these machines, I know what I'm getting into, and I'm willing to deal with the periodic disruptions that Fedora delivers. Fedora is a good Linux distribution on the whole, but it is what I would call a 'forward looking' distribution; it is one that is not that much interested in maintaining backward compatibility if that conflicts with making the correct choice for right now, the choice that you'd make if you were starting from scratch. The result is that every so often, Fedora will unapologetically kick something out from underneath long term users and you get to fix your setup to deal with the new state of affairs.

All of this sounds very theoretical, so let me make it quite concrete with my tweet:

Today I learned that in Fedora 31, /usr/bin/python is Python 3 instead of Python 2. I hope Ubuntu doesn't do that, because if it does our users are going to kill us.

I learned this because I've recently upgraded my work laptop to Fedora 31 and on it I run a number of Python based programs that started with '#!/usr/bin/python'. Before the upgrade, that was Python 2 and all of those programs worked. After the upgrade, as I found out today, that was Python 3 and many of the programs didn't work.

(Fedora provides no way to control this behavior as far as I can tell. What /usr/bin/python is is not controlled through Fedora's alternatives system; instead it's a symlink that's directly supplied by a package, and there's no version of the package that provides a symlink that goes to Python 2.)

This is fine for me. It's my own machine, I know what changed on it recently, I don't have to support a mixed base of older and newer Fedora machines, and I'm willing to put the pieces back together. At work, we've been running a Linux environment for fifteen years or so now, we have somewhere around a thousand users, we have to run a mixed base of distribution versions, and some of those users will have programs that start with '#!/usr/bin/python', possibly programs they've even forgotten about because they've been running quietly for so long. This sort of change would cause huge problems for them and thus for us.

Fedora's decision here is not wrong, for Fedora, but it is a very Fedora decision. If you were doing a distribution from scratch for today, with no history behind it at all, /usr/bin/python pointing to Python 3 is a perfectly rational and good choice. Making that decision in a distribution with history is choosing one set of priorities over another; it is prioritizing the 'correct' and modern choice over not breaking existing setups and not making people using your distribution do extra work.

I think it's useful to have Linux distributions that prioritize this way, and I don't mind it in the distribution that I use. But I know what I'm getting into when I choose Fedora, and it's not for everyone.


Comments on this page:

I know this doesn't solve the underlying problem (I agree Fedora is forward looking), but specifically for Python, have you tried Fedora Modularity?

By KC Marshall at 2019-12-11 15:22:39:

Too many of the built-in OS support tools assume they know what /usr/bin/python is, so changing /usr/bin/python (on any particular system) to match your expectations will basically break the OS (things like package management and system services). Since python2 and python3 are reasonably incompatible, I think the only real options are either explicit "python2" and "python3" binary names or custom paths that express the version.

By cks at 2019-12-11 16:16:31:

As a prequel to this shift, Fedora changed all of its packaged Python programs to use an explicit '/usr/bin/python3' for their #! lines (or '/usr/bin/python2', but I think none or almost none of those are left). As I understand it, the only things left running or using /usr/bin/python are user programs and people who type a plain 'python' at the command line.

Given this policy, it would be possible to allow people to control what /usr/bin/python is on a Fedora 31 machine. This would have the cost of two Fedora 31 machines differing on what version of Python that was, but the alternatives system is already sort of doing that for other things.

You may not like RHEL/Springdale 8. Have you built any RPMs yet using their new AppStream? I recommend you read up on it now if not. Many interpreters have no default at all, one must be included and specified at build time.

By cks at 2019-12-15 15:23:26:

I'm mostly indifferent to how RPMs (or Debian packages) have to be built, because we don't build our local programs that way; we just put them in our own separate filesystem hierarchy and manage them ourselves (and obviously our users can't build and install their own packages). Even on my personal machines it's easier to just have a $HOME/bin than to build RPMs.

For RPMs in general, I think that making them specify interpreter versions (especially for Python, Ruby, Perl, and so on) is probably the right choice. RPMs have been moving toward being more explicit over time, and this is an obvious next step given that various languages are introducing incompatible bits.

By Miksa at 2019-12-18 09:41:06:

Red Hat did the hard decision with RHEL8 to not have /usr/bin/python, standard packages provide only python2 and python3 binaries. You need to use 'alternatives' if you need "unversioned" python.

Written on 11 December 2019.
« It's a good idea to label all of the drives in your desktop
Linux makes your PCIe topology visible in sysfs (/sys) »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Dec 11 00:49:11 2019
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.