No date set
Stuff that is going to be turned on for Fedora 11, but basically complete:
Turn repo. gpgkey checking on by default
Stuff that requires an .sqlite schema change:
List full filelists as single entries (faster), also include file checksums
Yum API breakage?
rpm bindings change
remove some deprecated stuff.
This is the main stuff to do for Fed-11, just so I don't forget in my old age
- history DB
- group DB
- Look at GUI options
- client/server x509
We have a couple of usecases we want to fix, in decending order:
1. Download new packages in the background (while other commands can run).
Don't have "yum provides /blah" fail for normal users, when filelists doesn't exist (etc.)
Don't download data multiple times, when running repoquery as the user vs. root.
4. Be able to run two commands at once, for a single user.
...the obvious conclusion people see is that we need to go straight for #4 which thus. requires no locking, or "fine grained locking" which is hard (think two runs trying to use different repomd.xml on a repo, dito different sets of repos ... and always remembering --repofrompath).
However I have a "let's cheat and fake it proposal":
. 2 is just use misc.getCacheDir() for non-root instead of it implying -C, this fixes 2 but makes 3 worse.
. 3 means we have to do some work so we sync. between the "master" cachedir and getCacheDir() cachedirs better, the biggest problem/reward here is foo.sqlite existing in the master when we are looking for foo.sqlite.bz2 ... but there are other edge cases.
. 1 after we have 3, the easiest way to do this is to allow the code to do the sync in the other direction. Then we download packages to a local getCacheDir() type place and sync. back to the "master". rename is atomic, and we are just adding packages ... syncing back metadata is more problematic, but we could have a "/tmp" cache type thing.
. 4 could then be done by having the yum run from a getCacheDir() when the lock exists.
Work out some way to deal with more than one machine at once:
query UI, which machines have security updates, which need updates for BZ 123?
operate UI, make group X like box Y, fix group Y for BZ 123?
No date set
We now have checksum and lengths for all objects after metalink download:
Pass in name/url/checksum/len/etc. Have backend fail early if we go over our given length.
Integrate presto, do presto like stuff for metadata (not just packages).
Add APIs to allow async downloads of multiple objects.
Ability to share downloaded data over local network, avahi etc. -- needs integration with presto, and a real server to be written)
Dynamic fastest mirror instead of basing everything on one connect().
Make sure spacewalk works.
Move from having one global list of package keys to having per. repo. package keys, using the same set of keys as the repo. signing.
This requires hacking the gpgkey's out of rpms (koji etc. has hacks), or we wait for new rpm bindings (RHEL-8 :)?
NSS/FIPS checksums for packages (ie. sha256 instead-of/as-well-as sha1). Hack this in via. sha256:... in checksum column.
CA cert checking integrated (both ways).
Short term. stuff
- Translation updates
- Translation problems, which need code changes.
Long term stuff
- i18n search (probably == per. locale primary?)
- utf8 or unicode everywhere.
This is mostly somewhere to put all the kmod and Xz tickets.
In theory we could fix them eventually, but it's a non-trivial corner case.
Xz == rpmlib deps. ... latest upstream now outputs a message. It might even be worth outputting the "current rpmlib provides" ... if someone really cares we could download the latest version of rpm and look in the header to see if it fixes the problem.
kmod == kernel modules nightmare of the week, this will probably never be fixed outside of RHEL and using a small number of kmod packages.