yum todo list part 2
September 30, 2004
Icon spent a bunch of time profiling the metadata import today and then we brainstormed some. I think we might have some ways to make the importing of the xml metadata faster, especially on concurrent runs against the same xml files. He did some spiffy work, now we just need to make it function in use. 🙂
I sat down and made my self write up the stubs for the group functions and clean up yum/groups.py. Generic but not useless. 🙂
I also cleaned out my old todo list and made the new one and even prioritized:
- log output – to files and to console – make it nicer/real
- pre-transaction confirmation output needs to be clearer and easier to read
- group* functions (duh)
- transactioninfo.py needs fleshing out of methods and then cli.py and yum/depsolve.py need to start using it.
- Menno’s Xtrigger needs to happen once the transactioninfo class is in place
Less important but useful items:
- list output and function changes:
- yum deplist somepkg
- yum recent needs to be based relative to current date and limited to a package count
- yum list obsoletes should be dressed up so it lists the obsoleting and obsoleted packages easily – fitting all this in 80 chars is a pain
- ditto above with updates/updated
- sigcheck routine needs to handback siginfo from any successful check
- urlgrabber module IN yum needs to be renamed so it doesn’t conflict with urlgrabber on system
- yum-downloader code needs to be merged and cleaned
- yum-arch-legacy needs to show up in 2.1.X to make some folks happy
- urlgrabber needs to add socket timeout ability
- work to be done to make the optimization routines icon came up with to work with more than one repository, sanely
Anyone wanna help?
/me hears crickets
Came across a cool idea that Rick Graves came up with. He’s calling the scripts lagmirror. The idea is simple. The longer a package is in a repository without any update the greater the likelihood that the package is stable/safe.
So a package that shows up is in the day1 repo
after 2 days it’s in the day3 repo
but then a new package of the same name shows up. So the day3 repo notes this and that package never moves beyond day3. While the new package that just shows up starts over in day1.
So you could have really mission critical stuff be on like a day25 repo and your less critical stuff could pull from day3 or day4.
Now, granted it’s not a fullproof metric but in a large number of cases it is accurate. And it correlates nicely to the concepts of:
testing, unstable, stable that fedora, debian and other folks use for package/distro releases.