seth vidal wrote:
On Sat, 2008-03-29 at 16:08 -0400, James Antill wrote:
On Sat, 2008-03-29 at 09:11 -0400, seth vidal wrote:
On Sat, 2008-03-29 at 02:22 -0400, James Antill wrote:
Maybe this was more obvious to others, but:
yum --enablerepo=development upgrade
...takes about twice as long (and uses about 100MB more) as:
yum --disablerepo=* --enablerepo=development upgrade
well, you are diminishing the number of packages to search through by
about half.
Yeh, I tried to do some code so we can have "newest pkgs" data directly
in MetaSack so the sqlitesack code could say things like "if this pkg
isn't the newest, skip the requires/provides searches" ... but it wasn't
pretty, and didn't save much (roughly 10% RSS / 5% CPU).
So I had another idea, just do something like the above (which is
probably what the user would do if they knew) ... have a configuration
option in the repo section that says "when this repo. is enabled, these
other repos should be disabled".
With the following patch, I added the following (in the corresponding
repo. sections):
[development]
auto_disable_repos = fedora, updates, updates-testing
[development-debuginfo]
auto_disable_repos = fedora-debuginfo, updates-debuginfo,
updates-testing-debuginfo
[livna-development]
auto_disable_repos = livna
[livna-development-debuginfo]
auto_disable_repos = livna-debuginfo
...gives me about 33% CPU (30 secs from 45) 33% RSS (163MB from 243, VSZ
also down by about 80MB to 393MB from 473MB)[1].
Patch is at:
http://people.redhat.com/jantill/yum/patches/auto-disable-repos.patch
...the way it is there you can still do:
--enablerepo=development --enablerepo=fedora
...if you really want to.
So RFC time:
. Anyone think the feature is too magic? Any suggestions to make it less
magic (add option to disable, add log messages saying what we are
doing?)
. Anyone hate the config. variable name?
. Anyone want the option to be more powerful? Ie. if you have
updates-debuginfo on, and you do --enablerepo=updates-testing we
probably want to turn updates-testing-debuginfo on.
Seriously, I think this not something worth adding to yum. Maintaining
these lists is doom, especially as more repos get added/subtracted and
frankly if a user complains about yum being slow or taking up too much
memory and they're loading repos they aren't using then I think that
falls into the category of "Dr, it hurts when I do this! Don't do that,
then."
I agree with Seth on this one, i don't help people in the day to use of yum.
Tim
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
