In certain extreme situations, that are more likely if the install
state is old (e.g. 9 months +), Entropy may decide to remove packages
due to conflicts with the version being installed and shoot itself
in the foot, if this is the case of dev-lang/python :-).
So, this commit tries to avoid the scenario by filtering out package
removals for those that are being installed anyway as part of the
transaction (e.g. a system upgrade).
This should fix the very specific case, but increase uncertainty
and thus entropy in other cases where once a package that lists
conflicts is installed, it may not expect to find that package
installed. However, this case should be handled by the dependency
graph generator (and it currently does not), which would need to
reorder the execution of the queue to comply with conflicts.
Perhaps, someone in the future will improve that too, for now,
let's enjoy one more snowflake.
Current improvement:
- foo-1 and bar-2 are set to be installed
- foo-1 conflicts with <bar-2
- bar-1 is installed
- foo-1 wanted to remove bar-1 as part of foo-1 install transaction.
(now fixed, it won't...)
- bar-2 is then installed
Better improvement:
- foo-1 and bar-2 are set to be installed
- foo-1 conflicts with <bar-2 (but bar-2 itself can be installed
and does not conflict with foo-1)
- bar-2 is set to be installed before foo-1
- when entropy gets to foo-1 there is nothing to remove
We need to monkey patch isMainThread in order to return True for
the ActionQueueWorkerThread as well. This avoids EntropySQLRepository
to initialize an infinite number of cleanup monitor threads for a
thread that will never go away (the ActionQueueWorkerThread one).
We cannot sleep with the activity mutex held without affecting
parallelism so badly. Otoh, we cannot wleep on UpdatesNotificationResourceLock
without affecting 3rd party clients in a way that we would starve them
for a while. So, try to acquire the file lock in non blocking mode
and if it fails, reschedule a new call as soon as the same lock is
freed (exclusive acquire succeeds). This assumes that if the lock
is held back, we will just re-do the whole trick again and again.
