Bug 1038497

And it doesn't check whether rpm, smart or whatever is running either , nor should it. And vice versa, having all depsolvers and umphteen other related utilities know about each other explicitly just does not work.

Rpm forces serialization of the actual transactions for all users, however the plain serialization as-it-is now is insufficient (for one, it occurs too late), as eg the first-arriving transaction could remove packages which the later-arriving transaction would depend on.

Next major rpm version will allow better control over the transaction lock, ie they can grab the lock as soon as they see fit to do so. Likely it'll also allow callers to decide whether to wait for the lock or just bail out, and at the lowest level rpm will enforce the issue if caller didn't lock, probably by failing the transaction if it fails to grab the lock in rpmtsRun() instead of just waiting for the in-progress transaction to finnish (which is what it now does)

(In reply to Panu Matilainen from comment #1)
> And it doesn't check whether rpm, smart or whatever is running either , nor
> should it. And vice versa, having all depsolvers and umphteen other related
> utilities know about each other explicitly just does not work.
> 
> Rpm forces serialization of the actual transactions for all users, however
> the plain serialization as-it-is now is insufficient (for one, it occurs too
> late), as eg the first-arriving transaction could remove packages which the
> later-arriving transaction would depend on.
> 
> Next major rpm version will allow better control over the transaction lock,
> ie they can grab the lock as soon as they see fit to do so. Likely it'll
> also allow callers to decide whether to wait for the lock or just bail out,
> and at the lowest level rpm will enforce the issue if caller didn't lock,
> probably by failing the transaction if it fails to grab the lock in
> rpmtsRun() instead of just waiting for the in-progress transaction to
> finnish (which is what it now does)

It didn't seem to lock at all. 

One example is I had dnf updating about 1500 packages, and right in the middle of it I was able to yum install other packages. 

Are you saying in that split second while dnf was between packages yum snuck in and did its transaction? Kind of far fetched IMO..

I'm not saying all package manager should know about all others, but in the mean time at least dnf and yum should?

If yum and dnf can simultaneously install/update packages on the same root, that'd probably be a bug in rpm. Note that this doesn't include the depsolve + download phases, there's no reason why those couldn't be concurrent.

What's currently *should* happen is in the above case (dnf in middle of large update transaction, yum used to install something else simultaneously) is that yum should get stuck with "waiting for transaction lock on ..." message until dnf returns from rpmtsRun().

(In reply to Panu Matilainen from comment #3)
> If yum and dnf can simultaneously install/update packages on the same root,
> that'd probably be a bug in rpm. Note that this doesn't include the depsolve
> + download phases, there's no reason why those couldn't be concurrent.
> 
> What's currently *should* happen is in the above case (dnf in middle of
> large update transaction, yum used to install something else simultaneously)
> is that yum should get stuck with "waiting for transaction lock on ..."
> message until dnf returns from rpmtsRun().


Right, this definitely is not happening so I guess this is a bug in rpm as you mentioned earlier. I thought this was due to the fact that dnf wasn't using pid files and yum wasn't checking for them. 

Please test for yourself.

Tested with yum doing a large update and dnf used to install a small package simultaenously, so its the other way around from your test but it shouldn't make any difference as its rpm who does the locking here: 

The later transaction blocks after outputting "Running transaction" and does not actually start installing anything before the first one finished.
What's missing however is the "waiting for transaction lock..." message, or rather, its only shown *after* the the lock has been acquired, probably caused by yum/dnf transaction callback trying to record output from rpmlog.

I see no actual locking bug here, except for this kind of serialization not being sufficient in case of "conflicting" transactions and the logging issue above.

Oops, managed to edit out the fact that I tested this on F19. Shouldn't make a difference though as the rpm version is virtually identical on F20 and its rpm doing the locking, unless yum/dnf of F20 do something strange that defeats the fcntl() lock.

Also to clarify the "no locking bug" part: what I see is the current expected behavior from rpm POV, but as explained in comment #1 the way its serialized now is not fully correct.

Yum and DNF shouldn't care whether each other is running---you're supposed to use only one. There's more things that break when both are used.

DNF can run in two instances, it has granular locks (e.g. metadata is locked when downloading/reading it). The two DNF instances you run simultaneously were not stepping on each other's feed as explained by Panu.

Closing this as not a bug.