On Fri, Jul 04, 2003 at 11:24:51AM -0700, Andi Payn wrote: > I've included the new-and-improved version, which runs in a couple of > seconds....
The output contained some duplicated lines and differs from the version I posted (even after fixing the indent; see below) :( [..] > > > Also, I have a few questions: > > > > > > 1. Is there a faster way to do this than running urpmf ~5000 times? > > I already answered my own question--just read the synthesis file! Using urpmf would avoid possible breakage due to a synthesis file format change. The speed seems to be comparable. > > I've attached my version. Your version is still running, so I don't know > > if it works correctly. Please compare it with the output of your version. > > > > Don't forget to change the --media. > > When I try this, it doesn't work. When I type "urpmf --media > main-cooker,contrib-cooker --provides --obsoletes" at a command line, I get > back a usage error from urpmf. I was hoping there was some way to tell urpmf > to operate on everything (or at least operate on this list of files), but > leaving the package name off doesn't seem to do it. (I've got 4.4-8mdk, if > that's relevant.) Use "": urpmf "" --media main-cooker,contrib-cooker --provides --obsoletes > > > 4. Would anyone besides me want a python-URPM? (This would obviously take > > > some time, but I'd be happy to look into it.) > > > > Might be nice. > > OK, I'll look into it. Ideally it should provide the equivalent interface to > perl-URPM, right? I think so. It would make it easier to switch from Perl<>Python. This should convince Mandrake to dump Perl and go with Python. ;) > > > 5. Is there actually no python-expect or python-pexpect? Would anyone > > > besides me want it? (This would take a few minutes.) > > > > Searched for something like that last week. I found the following: > > http://sourceforge.net/projects/pexpect/ > > Yeah, I meant "is there actually no python-expect or python-pexpect package > for Mandrake," but I wasn't very clear. I've since found that drakian > provides a binary-only (alien'd) python-expect for python-2.1, but that's not > exactly what I want.... Agreed. > Anyway, I have the latest versions of pexpect, python-expect, and ExpectPy; > making packages for them should be trivial. In my opinion, pexpect is the > coolest (it's pure python, and it's tiny, it's just about as efficient as the > others, and it handles the 95% most common uses for expect exactly like the > real thing), but it might be nice to have python-expect or ExpectPy as well > (since they actually wrap expect, they handle 100% of all uses exactly like > the real thing--and, if anyone cares, they work with python 2.1). Pretty soon I'm going to play with Expect again. I've written lots of Tcl/Expect and while Tcl is fun, I sometimes wanted good and fast datastructures (like Python has). Keyed lists (from TclX) are very slow when you use them to store lots of data. [..] > --- CUT HERE --- > #!/usr/bin/env python [..] > if not provides.has_key(virtual): > provides[virtual] = [] > provides[virtual].append(package) The version I posted has the last line wrong (extra indent). -- Regards, Olav
