Changes between Version 2 and Version 3 of RepodataLocations

Show
Ignore:
Author:
james (IP: 65.172.155.230)
Timestamp:
09/27/10 22:52:47 (7 years ago)
Comment:

add some downsides

Legend:

Unmodified
Added
Removed
Modified
  • RepodataLocations

    v2 v3  
    3131 
    3232This 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. 
     33 
     34So if there is no downside to the user or developer, what are the downsides? The best I can come up with are: 
     35 
     36 * 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). 
     37 * 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. 
     38 * 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. 
    3339 
    3440=== Using packages, what are the downsides? ===