On 12/02/2014 01:57 PM, Pat Riehecky wrote:
> On 12/02/2014 01:07 PM, Orion Poplawski wrote:
>> On 12/02/2014 11:07 AM, Pat Riehecky wrote:
>>> I believe I've got a trigger based solution working.  Posted in 
>>> sl-testing
>>> just a moment ago.
>>>
>>> The script's Requires should be met by what they trigger against, so 
>>> I've
>>> excluded /bin/bash and coreutils from its Requires list.
>>>
>>> My testing seems to avoid the loop shown above (but it seems I was 
>>> lucky and
>>> didn't hit it much before).
>>>
>>> Can I get few external testers looking at:
>>>   sl-release-7.0-2.1.sl7.x86_64.rpm
>>>   yum-conf-sl7x-7.0-2.1.sl7.noarch.rpm
>>>
>>> Pat
>>>
>> I don't see the scriptlet errors on install anymore.
>>
>> Some other comments:
>>
>> - How do you end up with /etc/yum/vars/slreleasever if yum-conf-sl7x 
>> is not
>> installed initially?  Is that a problem?
>
> A trigger off of 'yum' when it installs.  It is a bit less elegant 
> than I'd like, but should get the job done without making a weird loop.
>
>>
>> - Scripts shouldn't be in /usr/share/doc:
>> /usr/share/doc/redhat-release/set-slrelease.sh
>> /usr/share/doc/redhat-release/slEULA.sh
>
> I can move them into /usr/libexec/sl-release/.  For the initial 
> messing around doc was conveniently already in the rpm.  I probably 
> should have just done that to start with.....
>
>>
>> - sl-release should probably own (via %ghost) /etc/yum/vars/slreleasever
>>
>>
> /etc/yum/vars/slreleasever gets handed back and forth a little bit 
> during the alpha/beta/rc period.  I've not really messed with %ghost 
> before.
> My quick test shows:
>   multiple RPMs can %ghost the same file without installation issues
>   multiple RPMs can %ghost the same file without installation issues 
> and a rpm which actually provides the file can be installed
>   when removing an RPM which %ghosts a file actually provided by 
> another rpm, the real file is left alone
>
> I think that covers all my edge cases.  My deep concern is that, 
> should $slreleasever be undefined, yum updates break and it becomes 
> difficult to push out a fix.
>
> So, since I've not a lot of experience on this I'm double checking the 
> behavior a bit with the community......
>
> Pat
>

Forgot to include link to handy chart of possible states: 
http://ftp.scientificlinux.org/linux/scientific/7/x86_64/release-notes/#_using_sl_yum_variables

-- 
Pat Riehecky

Scientific Linux developer
http://www.scientificlinux.org/