SCIENTIFIC-LINUX-USERS Archives

May 2018

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Nico Kadel-Garcia <[log in to unmask]>
Reply To:
Nico Kadel-Garcia <[log in to unmask]>
Date:
Wed, 16 May 2018 19:08:01 -0400
Content-Type:
text/plain
Parts/Attachments:
text/plain (50 lines)
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.

> {^_^}

ATOM RSS1 RSS2