Przemek Klosowski via devel wrote:
> On 11/5/19 7:18 PM, Kevin Kofler wrote:
>> "name mangling": Why is this a problem? First of all, it is not mangling,
>> it is suffixing. The original name is retained unchanged and nothing is
>> prepended to it, only appended. And, e.g., Qt 3, 4, and 5 are all
>> different packages, so why should they have the same package name?
>
> For this specific point, it is nice to have a generic name (qt, or
> python, or sqlite, or whatever) that describes the current, default
> version. Most of my databases don't care about sqlite2, so typing
> sqlite3 feels like some sort of cargo cult ceremony. I feel the same is
> true of most software---the ecosystem evolves and tends to be compatible
> with latest version of their dependencies. The suffixed names should be
> used only if the underlying system really cares about that specific
> suffix.
>
> This does not contradict any of what you said---just that I end up
> creating aliases (sqlite -> sqlite3, python -> python3, etc) that in my
> opinion should be provided by the distribution. It's not a big deal, in
> any case: maybe the biggest practical effect of all this is that default
> names promote keeping up with the ongoing development----it's harder to
> write Python2-dependent code if you have to explicitly invoke
> #!/bin/python2, as sort of a version-shaming.
You are talking about binary names there, whereas I was talking about
package names. Though of course, to get parallel-installable packages, any
included binaries typically have to be suffixed as well.
The drawback of renaming the binaries is that it breaks existing user
scripts (and also other packages). For Python, the Python SIG went through
with it anyway (unsuffixed Python is now Python 3, assuming you have python-
unversioned-command installed at all to begin with), also because they seem
to consider breaking everything Python 2 by default to be a feature. The
SQLite maintainer(s) decided differently.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
