Yes, aware.
I assume an innocent user action is leading to the error. I've never seen the issue, but I stay in a narrow range of method. I assume the issue is related to numerous tools trying to do the same job, even if done separately in a way we'd expect to be ok. IIRC a reboot doesn't help, so there is persistent state information from some utility. Auto updates seems to be involved, but there could be more than one issue.
Someone with the situation needs to do a thorough grepping of the journal/logs for clues. I *think* if something blocks the write to the (open) package list it doesn't know any better if the followup read passes.
Similar behavior can be induced on .xsession-erros within a session. The difference is that file is re-established in a new session. The package database list have no such refresh. Since an open or locked file won't survive a reboot, it must be a process started each time at least holding the file open without a lock.
I put my two cents on an auto update utility. So the question may be what package handlers or managers are installed.
