Next Change →
side by side
lines around each change
White space changes
09/27/10 22:52:47 (6 years ago)
add some downsides
This is mostly how updateinfo and groups etc. are distributed now, a single file is generated and then after you create the repository you run [modifyrepo] to add the file. There are then low level interfaces in yum (and I assume other packaging solutions) to just say "give me a pointer to the updateinfo repodata". There are also higher level APIs, for current repodata like updateinfo, but they aren't required. So there is '''no''' downside to using repodata, from an application developers point of view.
So if there is no downside to the user or developer, what are the downsides? The best I can come up with are:
* There is currently working deltarpm infrastructure, but no deltrepodata infrastructure. Adding that infrastructure should be possible, and would help any current and future repodata, but it is work. It's also not obvious how much this would help, esp. compared to just designing any repodata well (Eg. not one giant file).
* If a user runs "yum clean metadata", instead of say "yum clean expire-cache", then they'll currently need to re-download any metadata. If a significant number of users are doing this, and we can't stop them, this can be fixed by adding another caching layer.
* Although you only need a tiny change in release engineering to use modifyrepo, you don't even need this tiny amount if you use a package. Given the size of the changes needed though, this is tenuous at best.
=== Using packages, what are the downsides? ===
Hosting provided by