On 20180515 15:15, Orion Poplawski wrote:
On 05/13/2018 12:50 PM, Gilles Detillieux wrote:
On 2018-05-12 04:29, jdow wrote:
On 20180511 21:26, jdow wrote:
I have yum-conf-sl7x.noarch installed. 7.5 seems to be out. But yum update
still leaves the system declaring it is 7.4.
{o.o} Joanne
At least that's what I get on one system. The other is still declaring 7.3:
[... /etc]$ cat /etc/yum/vars/slreleasever
7.3
Shouldn't that read 7.x or something else if it's really following 7x?
I've found that sometimes yum-conf-sl7x doesn't properly update
/etc/yum/vars/slreleasever. I suspect it might be because that file is
shared/co-owned by yum-conf-sl7x and sl-release packages, and yum seems
sometimes to get confused as to whether the config file should be updated or
not. That happened on a few of my systems going from 7.3 to 7.4, but not with
the recent 7.4 to 7.5 update. My fix was to copy the updated slreleasever file
from an updated system to one that wasn't updating. Someone else has suggested
removing and reinstalling the yum-conf-sl7x package:
https://www.mail-archive.com/[email protected]/msg04927.html
If all else fails, you could try manually updating the slreleasever file:
echo 7.5 > /etc/yum/vars/slreleasever
Yeah this system just isn't robust. Which ever of sl-release or yum-conf-sl7x
is installed last "wins". So currently after every new point release you'll
need to reinstall sl-conf-sl7x or echo 7x > /etc/yum/vars/slreleasever.
It might be possible with the use of rpm triggers to have yum-conf-sl7x "fix"
slreleasever after every update of sl-release.
Perhaps:
%triggerin -- sl-release
echo 7x > /etc/yum/vars/slreleasever
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
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
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.
{^_^}
