On Sun, 2008-01-20 at 19:16 -0500, seth vidal wrote: > I gave a talk on yum at fudcon. It was fairly well attended. I decided > to preempt the 'yum sucks' portion of the talk by putting up a white > board with 'yum problems' written across it then asking for what > problems people have with yum. > > Here's the list I got, some of them were suggested by people with less > than complete sincerity: > > - it's not apt :)
Well generally when I've seen that it's a keyword for something else, usually speed ... sometimes the fact that apt-get does metadata downloading only when specifically asked to do so (which, IMNSHO, is a terrible way to do it) ... sometimes the higher level UIs. > - no bittorrent support :) So I assume the main problem is that people see package downloads take a long time, and maybe that they aren't running at full speed? With the list-data plugin, I can see (fully updated Fed-8 from within a week or two): % yum list-package-sizes updates [...] ==================== Updated Packages ==================== [ 0KB - 10KB ] 9 ( 9%) [ 10KB - 25KB ] 8 ( 8%) [ 25KB - 50KB ] 8 ( 8%) [ 50KB - 75KB ] 5 ( 5%) [ 75KB - 100KB ] 4 ( 4%) [ 100KB - 250KB ] 15 ( 15%) [ 250KB - 500KB ] 13 ( 13%) [ 500KB - 750KB ] 7 ( 7%) [ 750KB - 1MB ] 5 ( 5%) [ 1MB - 5MB ] 11 ( 11%) [ 5MB - 10MB ] 4 ( 4%) [ 10MB - 50MB ] 5 ( 5%) % yum list-package-sizes installed [...] ==================== Installed Packages ==================== [ 0KB - 10KB ] 97 ( 4%) [ 10KB - 25KB ] 121 ( 5%) [ 25KB - 50KB ] 148 ( 7%) [ 50KB - 75KB ] 106 ( 5%) [ 75KB - 100KB ] 83 ( 3%) [ 100KB - 250KB ] 305 ( 14%) [ 250KB - 500KB ] 287 ( 13%) [ 500KB - 750KB ] 161 ( 7%) [ 750KB - 1MB ] 108 ( 5%) [ 1MB - 5MB ] 442 ( 21%) [ 5MB - 10MB ] 100 ( 4%) [ 10MB - 50MB ] 119 ( 5%) [ 50MB - 100MB ] 14 ( 0%) [ 100MB - 500MB ] 4 ( 0%) ...so apart from the "couple of thousand lines of code extra" problem, I think that some of the package sizes are big enough for bittorrent ... however I think we might be able to easier solve the problem people are having by: 1. Getting background downloading to work in yum-updatesd. 2. Doing downloads as a parallel operation, from multiple mirrors (this requires urlgrabber changes). 3. Having a "total downloaded" progress meter of some kind. 4. Maybe having yum upgrade doing background downloads too. 5. Maybe having yum do "upgrade -y" not do a single large transaction, but do smaller transactions. ...#2 might actually make the downloads faster, the others are mostly about user perception. > - yum log format lacks the year (also worthy of note it lacks the > century and eon) - but the original point is not without merit Well atm. it's the same as syslog, not that I wouldn't also like a different date format in /var/log/messages _too_. > - groupupdate and group state tracking. Currently, the heuristic to > track the state a yum group* group is in is a little hairy. I'm not sure what you mean here? The only big thing I know that's missing is being able to say things like "list updates --groups=..." but it doesn't sound like you mean that. > - make the search returns faster (also make the searching not lockup on > common words (known bug)) Well from doing a 3.2.8++ release, I looked at all the patches post 3.2.8 and probably about half are to do with speed improvements. And I've seen people say 3.2.8 was significantly faster for them. And from what I've measured the only way we are going to make search/list much faster at this point is to just not load as much data (Ie. push the filtering all the way down into sqlite) ... which looks pretty non-trivial. But maybe I've missed something. > - add/deal with non-requires relationships > (suggests/enhances/recommends) This requires quite a bit of work in Fedora/whatever though. > - clean up/vet the docs b/c a lot of them are out of date or just wrong """ Well, guys, it is exactly why I hate to write docs: nobody read them in any case and I know it, because I do not read docs too. 8) Alexey Kuznetsov <[EMAIL PROTECTED]> """ :) -- James Antill <[EMAIL PROTECTED]> Red Hat
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
