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: 
>> [log in to unmask]" target="_blank">https:[log in to unmask]
>>
>> 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.

{^_^}