RPMWild Wiki

Type wildcard matches into the search boxes to match up to the rpm you want to delete. I know I warned everyone that it will delete any rpm including ones that you need to run your system - but it also asks you to confirm that's what you want to do. It won't just nuke your database without any warning. RMB click on the list of packages that come up and select "remove", that add the package to the transaction. Just quit if it looks like your transaction will destroy your systems ability to function. The reason I wrote this program was so I could graphically select and delete matched packages with no transaction checks. This functionality also makes it dangerous :D you've been warned.

I have done some work on the program so it's actually useful now...I promise, hah hah. When I upgraded to fedora 25, I used it to delete the fedora 23 packages that were still hanging around and all the dependencies as well. It can be used in a dangerous fashion, like if you type in kernel then select the kernel to be deleted and no check turned on. Then you have to select OK as well. So the program is extremely safe, when it comes to destroying your system. Now you can perform as many erase transactions as you want because I used a couple of transactions. The multi threading on the callback for rpm erasing with the progress dialog is still a work in progress.... so to speak. Only because it shows the progress on a single package that you are erasing(the first one). I will fix that later. There's some kind of UI bug as well, in the child window, I'll work on.

ok! I think this is the final iteration on it's functions, maybe. Now after you have selected packages to remove, you can edit the transaction. Click on the label of the package you don't want to remove, and it takes it off the list of packages to erase. So, now you can add and then remove packages from a list to erase and test it's dependencies or not, and erase them. The only thing it's missing is a check on the status of the transaction after it's over. I fixed up the UI a bunch. Also cleaned up the code, with proper tabs, and got rid of unwanted functions. I think the progress bar works, but we'll see. The rpm callbacks were... umm strange.

I changed the UI so the exit button is on the top. Also now it highlites the package name to erase when you RMB and the menu pops up. And I read the python code, to determine the results of rpmts.run(), then changed the program to match. Removed unused callback checks and hard coded garbage IDs....etc made it easier to understand what is going on.

Interesting, but I found the bug in my program is actually generated by the text entry field. It will only work "properly" with no error as long as it's set to wx.TE_MULTILINE as the style. so it doesn't look like a bug I created, it's more like a bug in pango or gtk or wx or something underlying.

hah the nuts upgrade to wxpython-phoenix fixed all my problems. It's like they knew what really irritated me about wxpython and got rid of that part. Also, I was looking at the code performed by the popup menu, and decided it was garbage. Trimmed it down huge to use the list of headers generated from the transaction match. It was performing another search for some reason. I don't really understand the purpose of that old code from like 5 years ago. Probably didn't get around to looking at it before because it worked and I was lazy.

well the transition to wxphoenix cleaned up some of the code. now there are dialogs instead of modal frames. The popup menu I completely overhauled using the latest example code from source. Looking at all the changes, it really made the code less bloated and capable of more. Could probably merge the 2 dialog classes into one single class if I really put my mind to it. I will keep testing the capabilities of wxphoenix.

I fixed up the popup menu code so now when you are viewing the matching list of rpms you can RMB on the grid label and the popup menu has another entry for "Info" which will make a popup window that contains the information from the header. I might change it to a dialog with a multiline text that displays the info. The popup is the same if you are editing the transaction or creating the transaction. You don't need to use the popup if you are editing, just a click on the label and it'll remove that from the transaction.

ohh by the way, it was hard to find popup menu code examples for what I was doing. Feel free to explore this code, I think it'll work for wxpython and wxphoenix.

well I did some good things to the interface, like how it closes the dialog when there are no rpms left to erase. Greys out the remove on the popup if you have added it already. I think the only thing left is context sensitive help. That'll be the polish it needs to shine. I'm really enjoying the progress bar and new interface setup. I can't wait to apply this to my older python programs.

I am going to add a thread to the program, so I can give some indication of action during the search. I have used threading before, it's not that hard to code up.

hmmmm well I added a custom event and whatnot, but sadly it was no different than using no thread for the search. Except I could actually perform several searches at the same time. But that was useless, who wants to search for python 3 times in a row and get three results exactly the same in a row? Definitely overkill. But, I will use the new search progress indicator I whipped up. It makes a popup under the greyed out search window that says "searching", so you know something is happening and it's not just sitting there. I'll keep the threading code around for a bit I might find some use for it.

What my program actually needs is multiprocessing. I found the threading to only ever execute a single thread at a time, each waiting for the other to reach completion and never using like 2 threads at a time.Or.. only ever using two threads - one for main and the other for a sub process. not very useful

yah, it seems multiprocessing has made it way faster. The threading was hard to see any gains, but now the database query that returns all software packages only takes a couple of seconds. name: * that used to take a while, so I was making a progress indicator to show the program wasn't frozen. Now, it seems like a demon as it performs the database search in a seperate process then ships the information in a queue to the main thread. I'll refine the code a bunch then update the source.

actually, that last update generates an rpm not installed message when you try to do the transaction check. Perhaps the multiprocessing is screwing up the transaction heh heh

I think I get it... the thread is passing a list of objects, but they are not part of the main thread. I have to pass the transaction to the process, instead of opening it there.

sadly the process queue was a bust. The objects coming out of there, despite having the right name, and details...were not accepted by the transaction. I suspect the python rpm stuff isn't thread safe or something??