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/