On Tue, May 15, 2018 at 7:09 PM jdow <[log in to unmask]> wrote:
> After actually getting "yum-conf-sl7x" to work it appears it is an
abbreviation
> for "yum-conf-sl7x-7.5-2.sl7.noarch". It appears this loaded the
slreleasever
> with 7.5, which is the current 7x. Until there is an update for
"yum-conf-sl7x",
> meaning something like "yum-conf-sl7x-7.6-?.sl7.noarch", fill in the ?
later, it
> reads from 7.5.
> It appears that this may not really work until the "yum clean all" is
run. I
"yum clean all" clears, among things, the locally cached metadata.That data
expires eventually, even without the "yum clean all". But if you've changed
where your repos are synced from, *which I'll bet happened when did this,
even if you didn't notice at the time*, then it would talk to the new
upstream host for metadata. Also, if they
/etc/yum.repos.d/[whatever-sl7x].repo file had been manually disabled at
some point or pointed to an out of date local mirror, then deleting the
yum-conf-slx package and re-installing it manually could clear that
somewhat disabled state.
I've come to really suspect that you wound up, by hook or by crook, with a
mangled sl7x yum configuration that was not pointing to current repos, or
was disabled. What you describe above would clear that state.
> don't know if that can be run from inside the update to "yum-conf-7x" or
not.
> The symptoms I had after installing yum-conf-7x agree with the "proper"
command
> sequence mentioned in Takashi Ichihara's post (remove,install,clean all,
update)
> suggest that it cannot, which more or less makes the 7x concept not work
right.
> However, there may be an initial pump priming needed after the 7x conf
install
> with everything working as desired thereafter. I honestly don't know if I
did
Yes, but this would have occurred automatically: the timeout of
"metadata_expire" is typically set at 6 hours, in yum/__init__.py .
> the "clean all" step when installing 7x on the two machines that seemed to
> behave oddly. At any rate, I think I have it solved for now.
> {^_^}
|