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

-- 
Pat Riehecky

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