According to the explanation, this situation is caused by user action. They’ve done something on their system that should normally not be done. So the expertise required to create the problem is sufficient to solve the problem I think.
But since this type of file conflict is common during updtes, maybe it is something to be suggested in Manjaro Development.
Even if we happen to know what exactly make this file appears and prove it, it won’t make the problem disappear magically to users in Stable that might be affected by it. The harm is already done on those systems. Knowing that it can happen in Stable to some (fortunately not every) users, since it just needs a file removal to fix it, I’m still strongly in favor to automate it.
Last time Manjaro asked its users to do a manual intervention in order to upgrade their system, it didn’t turn out very well. Ok, it is far less critical than this one since a file conflict prevents the upgrade completely, so it can’t really break the system. But is it still a problem that makes the upgrade not smooth, and we have the tool to make the upgrade smoother.
If nothing is done, there will be people who will ask for help. There will be people who will ask for help even if the solution is clearly documented. Hopefully no one will throw the RTFM post when it’ll be asked for the 20th time.
Perhaps a post should be done, yes. Maybe tomorrow (if not already done by then).
is simply a ‘compiled’ version of /usr/lib/python3.7/site-packages/PyQt5/__init__.py
and that __init__.py is kind of the starter for all of PyQt5.
__pycache__ directories and .pyc files are made by the Python interpreter when it imports .py files for the first time. So you could delete the whole __pycache__ directory, and Python will create it again if it’s needed.
As a long-time user of Python, I thought everyone knew that
(and maybe Jonathan thought so too…)
Qt5 underpins KDE, but I don’t know if KDE use PyQt5.
PyQt5 is on my system at that location, and I thought I installed it myself, but there’s no __pycache__ dir, as if it hasn’t been ‘imported’ by any Python app.
Hmm … the fact that you get that error while upgrading means … what?
Why does pacman not just overwrite it? – that’s what it does to most files, isn’t it?
Pacman never overwrites files that don’t belong to packages by default. If you want to overwrite a file with one provided by a package, you must explicitly ask pacman to do so with the --overwrite option.
I maybe thought that my .xprofile settings maybe causing it because I enabled global menus long before they were official so I had few related entries there. I commented them out, rebooted and still the same so I guess those entries doesn’t matter anymore and were not causing anything bad, so I guess we are left with waiting for a new KDE framework in hope it will be the fix.
On my KDE i didn’t have this file conflict. Maybe I haven’t ran python as root?
If I understood the issue (not a python user) the packagers know their code (python), so they assume “noone” ran python as root, so…
Then the users that came to Manjaro, looking for a “noob-friendly” experience should learn what’s the proper definition of this, like @jonathon often explains… (no need to repeat here, it’s already in numerous topics about these terms).
It maybe the difference between
“Learning in the classroom” by others’ mistakes/experience (=RTFM)
“Learning on the job” by own mistakes/experience (=WTF)
Hope is based on information I was given, so it’s not completely baseless. As to checking cloned global menu in journals, I wouldn’t know what to look. I can see on my own eyes doubled menu and also asked here if that’s just me or others have the same issue - it was confirmed, so this exists.
I just wait for the new Plasma and KDE framework. If that won’t fix it, then I’ll start investigating and reporting. The general issues with LO menus in Plasma are marked as fixed so instead making a panic, let’s wait a bit. New packages should arrive pretty soon.