Upgrading OSG Software from Development to Testing
I'm going to go through my process (as I do it) of upgrading the osg-wn-client from development to testing.
Check Jira for tickets by component. For the osg-wn-client, I look at: osg-wn-client:
- Major: SOFTWARE-30: Add LSC files to the vomses. This bug has a first draft of the documentation done. It also is not a functional show stopper, rather it only affects the packagers.
- Minor: SOFTWARE-78: Pegasus RPM cleanup / FHS. This is a feature request/task really. Though nice to have, it doesn't change the functionality of the package.
koji tag-pkg el5-osg-testing bestman2-2.1.1-5
Once you have tagged all the builds that are dependencies of osg-wn-client, you can upgrade the meta-package. Then it's time to pull out the VM. I need to test the install, see if I caught all the packages. Since we're upgrading so many packages all at once (likely a one time thing), we need to test the install along the way.
Luckily, I have mash running on a local server, so I can just execute mash to pull the latest from the testing repo. If you want my mash configs, they're on github: https://github.com/djw8605/osg-mash. I needed to edit the /etc/yum.repos.d/osg-testing.repo file in the VM in order to point to my local mash repo.
I did have missing dependencies: gfal, libglite_data_delegation_api_simple_c.so, libglite_data_util.so.0, libglite-sd-c.so.2, vdt-ca-certs. Another iteration (after yum clean all)... Missing libglite_data_delegation_api_simple_c. Another iteration... success!
To find what package provides what library, I just use the web interface, clicking on the RPM's info, to find what the package Provides. I'm sure there is a clever yum command to do most of this for me, but this didn't take me much time anyways.
So, we now have a osg-wn-client in the osg-testing repo. Stay tuned next week for the upgrading of the osg-client. Just need to resolve the blocker ticket for the osg-client.
Leave a comment