Description of problem: When running an incredibly long update, or installing a larger set of packages, you are currently unable to install anything else. This makes sense, and yet it is still somewhat annoying. As I type this, I am updating a live flash drive with persistence, and it is taking a long time (cheap, slow drive). I would love to install a couple small, non-conflicting packages while this process is going on. I can't. Version-Release number of selected component (if applicable): yum-3.2.27-4.fc13.noarch How reproducible: Currently expected behavior. Steps to Reproduce: 1. Run 'yum update' with lots of updates waiting, or 'yum install' a large set of packages 2. While that's running, realize you'd like to play a game from bsd-games and run 'yum install bsd-games' in another terminal Actual results: Install waits for lock to go away before continuing. Desired results: Install checks currently running transaction(s) to make sure the requested install doesn't conflict (files, dependencies, whatever), and then proceeds if there is no conflict. Additional info: Before you get upset or you think I'm nuts, let me just explain that I merely want to throw this out there to see if I can give someone an itch to scratch :-). I do not have any programming skill, and I don't expect to get to a point where I could actually help implement such a thing. I just thought it might be possible, and I want to see if no one else has thought of it before. I am willing to test it should it ever hit rawhide. In addition, I apologize if this should be against rpm, as I'm sure changes would need to be made there just as much as yum. I have seen little rumblings of combining rpm and yum into one tool, so maybe that could be related to this. I wasn't sure which component would be more appropriate, so I picked yum as it's the interface that would most likely be used for this. And finally, I totally understand if this gets closed as WONTFIX or something. I know it's a bit out there, and I've already stated I can't personally contribute code. But to answer why I filed it here and not in the upstream bug system: I have an account here, I don't want to create a million accounts all over the place, and I know I can trust Fedora to do right by an idea if contributors consider it worthy. I have seen Fedora take all kinds of awesome ideas and make them happen since I started using is back at version 6. You guys rock, and I trust you to make the right decision. And one last note: I regularly read the devel list's archives, but I'd rather not send messages to it. If someone with more knowledge and pull should happen to read this bug report and desire to start a discussion on the devel list, I would be more than honored that someone cared. I'll look forward to reading the discussion should it come about.
Multiple writers are not allowed in rpm. It's a relatively unsafe practice anyway b/c of the race conditions that spring up when multiple processes may attempt to update a single rpmdb at the same time. You can reassign this to rpm, if you'd like, but it is a cantfix/wontfix from yum's perspective. and I don't know where you're hearing combining rpm and yum into one tool - but that is extremely unlikely to happen.
I think this is what I was thinking of, which I now realize doesn't hold any more weight than a very light feather: https://fedoraproject.org/wiki/JamesBowes/NoRpmCommand Anyway, I would agree that combining the two wouldn't be likely or good. I guess my brain took that old draft of a feature proposal and gave it more importance than it should have. I am going to try my hand at reassigning this to rpm, just to see if I can get someone's eyes on this who might have a flash of brilliance on the subject ;-). Thanks for your prompt reply, and for prompting me to look up that bogus feature proposal. I apologize for the general noise of this RFE, but I really felt strongly about throwing the idea out there.
Opening this back up against rpm.
Re: comment #1 MUltiple writers are not allowed iff rpm chooses to use Berkeley DB with a concurrent access model.
Multiple writers is just a one piece of the puzzle, concurrent transactions would require different instances of rpm to know what the others are doing/about to do. The amount of work is not justifiable by "would be nice", but should the necessary infrastructure around this get implemented for some other reason then .. maybe someday. WONTFIX for foreseeable future though.
FYI: There's actually a technical name describing the details for ... different instances of rpm to know ... called level 0, 1 and 2 isolation for "transactions" and two phase commits. And "Transactionally Protected Package Management" (for the database) is already implemented and released @rpm5.org. ACID behavior for syscalls (like writing files onto the file system) has been prototyped, and "scriptlet ACID" has been modeled for RPM by Mancoosi WP3.
I just want to say I appreciate that you all took the time to comment on this. I understand it's probably more work than it's worth, but I just had to throw it out there :-). Hopefully, I've planted a seed in your brains that will grow as time goes on so you might implement this some day ;-).