Patrick O'Callaghan wrote: > Neither does 'dnf info ...' nor 'dnf search ...' so it's either a > pretty serious defect or the package is poorly named. Embedding the > specific version of Python in the package name doesn't seem like a > future-proof strategy in general. The package is named properly and per the guidelines for python modules¹. Without having python2 and python3 prefixes it is not easy to move the default python from 2 to 3, as is being planned. Including the python version in the package name is what makes it future proof. This is also why the packages have a python-$module provides. Most often this currently points to the python2-$module, but can be easily changed to python3-$module after the switch. Folks that want or need the specific python2 or python3 version of the module can still install it. And those who don't care can just install python-$module. Packages which contain applications that are written in python sometimes ship the application in a separate package which depends on the python module, allowing it to be installed by the application name, keyring in this case. The main issue I see is that many users expect dnf list to do more than it does. But yum list behaved this way as well (and still does on el6/el7). It may just be that less people noticed until python-$module packages were changed to python2-$module to aid in the migration to python3 as the default python. ¹ https://fedoraproject.org/wiki/Packaging:Python -- Todd ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I have never let my schooling interfere with my education. -- Mark Twain (1835-1910)
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
