Re: Back Again
- From: David Boles <dgboles@xxxxxxxxx>
- Date: Tue, 31 Jul 2007 20:51:49 -0700
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:I don't know if you've ever upgraded Fedora from one release to the next.
Nah, it's not closer. It's just that rpm is getting crappier everyI could easily be mistaken, but AFAIK, the main difference in speed
year, and is long overdue for replacement.
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.
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
- References:
- Re: Back Again
- From: Sam Varshavchik
- Re: Back Again
- From: Todd Zullinger
- Re: Back Again
- From: Sam Varshavchik
- Re: Back Again
- From: David Boles
- Re: Back Again
- From: Sam Varshavchik
- Re: Back Again
- Prev by Date: Re: scrambled panel & x-session loss: another update
- Next by Date: Re: Back Again
- Previous by thread: Re: Back Again
- Next by thread: Re: Back Again
- Index(es):
Relevant Pages
|
