Miroslav Suchý <msuchy@xxxxxxxxxx> writes: > I have interested situation with yum-rhn-plugin: FYI. you probably want the yum-devel ML. > In yum-rhn-plugin in init_hook we look for cached information of > channels and create dummy repos pointing to conduit.getConf().cachedir > > In prereposetup_hook we connect to Spacewalk/Satellite and replace those > dummy repos with repos pointing to channels on Spacewalk/Satellite. > > So far so good. > > But when you have only rhnplugin and no other repo and you do: > rm -rf /var/cache/yum/* > yum update # or any other command > I get: > There are no enabled repos. > Run "yum repolist all" to see the repos you have. > > This is because we have no cached repo (we deleted it, but same > situation will be just after kickstart) and the function > checkEnabledRepo() is called before prereposetup_hook. > > My question is: what is semantics of prereposetup_hook? Is it intended > to setup the repo, or just to configure them? > > In documentation is stated: > prereposetup > Called just before Yum initialises its repository information. > > I tend to think that checkEnabledRepo() should be called *after* > prereposetup... This is probably just confusing terminology, and movements within core to do as little as possible until absolutely required. Plus RHNplugin's kind of unusual requirements :) There are multiple stages for a "normal" repo: 1. Existing on disk, but yum hasn't loaded anything. 2. Loaded from disk. At his point it's in yb.repos has all it's configuration etc. (is enabled/disabled). 3. "Activated", so that repomd.xml for the repo. is now valid etc. ... prereposetup/postreposetup are done around #3, and a number of things (like checkEnabledRepo()) don't need that level of info. ... so just ask for #2 (basically calling yb.repos calls _getRepos() and gets you #2). I'm pretty sure you want to convert to "real" repos. at #3 time (aka. prereposetup). For the loading the cache case, I think ideally we want a "postrepoconfig" hook, that happens at the end of _getRepos() and you can hook into that. Atm. though, I'd just keep it in init_hook / config_hook. We can probably do something "clever" so that you can test to see if prerepoconfig_hook will get called, and if not then just call it directly from the end of init_hook. Other stuff, like auto-update-debuginfo, use prereposetup ... which is somewhat wrong, but they are pretty much guaranteed to have other repos. around to fake out the code between #2 and #3. to work around it would be to always add a fake "rhn" repo. ... this might be considered horrible though :). -- James Antill -- james.antill@xxxxxxxxxx _______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxx http://lists.baseurl.org/mailman/listinfo/yum
