Re: prereposetup_hook() vs. checkEnabledRepo()

Miroslav Suchý <[email protected]> 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 -- [email protected]