On 12/02/2014 01:59 PM, Pat Riehecky wrote: > 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 > I've updated the testing package per your feedback. Thoughts? Pat -- Pat Riehecky Scientific Linux developer http://www.scientificlinux.org/