on 7/31/2007 7:59 PM, Sam Varshavchik wrote: > David Boles writes: > >> on 7/31/2007 7:03 PM, Sam Varshavchik wrote: >>> Todd Zullinger writes: >>> >>>> Sam Varshavchik wrote: >>>>> Nah, it's not closer. It's just that rpm is getting crappier every >>>>> year, and is long overdue for replacement. >>>> I could easily be mistaken, but AFAIK, the main difference in speed >>>> that end users notice between yum and apt is due to the fact that apt >>>> caches it's metadata. In between runs of apt-get update, calls to >>>> apt-get use the data on disk without hitting the network. With yum, >>>> the update and upgrade steps from apt-get are both done in the update. >>> I don't know if you've ever upgraded Fedora from one release to the next. >>> The upgrade process is as slow as molasses, even though all the metadata is >>> right there. >> >> Do you know just why an upgrade of a system 6 months old, or more, takes >> longer than a fresh install of a new release? You should study that >> situation. Start with package dependencies and then think about just what >> you might have changed and added from third party sites. Then think some more. > > Well, I did think. The system does not have anything beyond Fedora and > Fedora Extras, plus my own RPMs. But why does it matter, anyway? Why does > the presence of a foreign RPM cause such a nervous breakdown? At most it > should result in an unsatisifed dependency. But why would should this result > in rpm spinning its wheels, to such an extent? > >> Care for a really stupid example? Take a 2006 automobile. Examine it very >> closely. Then with a garage full of new 2007 parts make it a 2007 >> automobile. All the time making sure that everything fits and still works. >> >> Email us when you're finished. > > No matter which parts you do have in your automobile and where they came > from, when you have to compare its part with a fixed list of two thousand > other parts, from a reference model, it should take the exact same amount of > time whether all your parts are OEM or aftermarket. It's the same number of > parts in your car, whether original or replacement, after all. So why would > it matter? > > At most, the complexity of what RPM has to do would be O(N), and it should > really be O(log N). But it seems, though, that RPM's actual complexity is at > least O(N^2), unscientifically. > > I tell you this. I mentioned before that I use my own package management > tool internally to manage some homebrewed software. I have a compatilibity > shim that sucks out pretty much the entire contents of the system RPM > database, and imports all of the dependencies into my internal package > database. This is to allow my own packages, which might have, say, a > dependency on something.so, have the dependencies satisified by an RPM. > > Basically, I read all RPM resources, and create a dummy package that > provides those resources, then install the dummy package, so my internal > package database contains all the RPM-provided resources. Each time I update > some RPMs, I rerun the import script and upgrade the old dummy RPM > compatibility package to a new one. > > This operation, you understand of course, is analogous to your example -- > taking an old snapshot of the entire RPM database, comparing it to a new > one, and reconciling any differences against resources required by my > internal packages, to make sure that they don't break. This operation is > also equivalent, to what Anaconda has to do when it's about to upgrade the > Fedora distro -- take the current RPM database, and reconcile it with the > RPM database from the release you're updating to. > > It takes me, oh, maybe a minute or so to crunch everything together. The > analogous step in Anaconda -- "Preparing transaction" -- takes aout 5-10 > minutes. > > And I actually have more work to do. RPM has, I believe, three resources > classes to reconcile against each other -- provided resources, required > resources, and conflicting resources. My internal package database has six > resource classes to reconcile, so I actually have more work to do. > > The performance degradation that I see in Anaconda is far more pronounced on > less-robust hardware. On my less-than one year old laptop, with a fairly > speedy Pentium, and 2 gigs of RAM, Anaconda is about 2-3 times slower than > my homegrown code. On an old box that I have, running a pair of decade-old > (approx) 500 Mhz Celerons, with 256MB RAM, rpm is dreadfully slow -- about > 10-15 times slower than my homegrown code. There's something terribly > inefficient in the way that Anaconda goes about its business. It should > /not/ take that long to do its duty. > > Some of it might be due to Anaconda being Python code, and my homegrown code > being C++. Great idea. But you really don't have a clue do you? Ok. You *don't* like the rpm/yum/Anaconda system? Write your own rpm/yum/Anaconda typesystem in C++ to replace the python one that Fedora uses. I am sure that the Fedora people would look at it. Programing is not my 'thing' But if you can replace their system with a better one I would be more than happy to try it. And, if it works, use it. As long as it is FOSS of course. ;-) If you're gonna' talk the talk - ya gotta' walk the walk. Nuf Sed? -- David
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
