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/