does not respect UPS (OVERRIDE) flavor
Over 2 years ago, I added a feature request #18209 to basically move the "get-directory-name subdir" functionality
from cetpkgsupport to ups. Now, I'm having a problem where I'd like to run some slf6 products on sl7 (specifically
artdaq_core, art, osddsimd), but the product table files call get-directory-name which returns the non-optimal (does
respect ups flavor) subdir name.
#3 Updated by Christopher Green 8 months ago
- % Done changed from 0 to 80
- Assignee set to Christopher Green
- Status changed from New to Assigned
You shouldn't have to override
CET_PLATINFO, just make sure that the environment cache variables
CET_SUBDIR are unset at the time you invoke
get-directory-name or (re-)set up
cetpkgsupport after setting
$ printenv | grep -e UPS -e CET | sort -u CETPKG_INSTALL=/home/greenc/work/cet-is/products CETPKG_J=25 SETUP_UPS=ups v6_0_8 -f Linux64bit+3.10-2.17 -z /products UPS_DIR=/products/ups/v6_0_8/Linux64bit+3.10-2.17 UPS_SHELL=shNote the lack of
Simple test of default behavior:
$ setup cetpkgsupport $ printenv CET_PLATINFO CET_SUBDIR Linux64bit+3.10-2.17:slf7:x86_64 slf7.x86_64 $ get-directory-name platinfo Linux64bit+3.10-2.17:slf7:x86_64 $ get-directory-name subdir slf7.x86_64Now clean up:
$ unset CET_SUBDIR CET_PLATINFOSet
UPS_OVERRIDEas we would wish (note the full flavor):
$ export UPS_OVERRIDE="-H Linux64bit+2.6-2.12-sl6-10" $ ups flavor Linux64bit+2.6-2.12-sl6-10Now:
$ printenv CET_PLATINFO CET_SUBDIR # Still empty: nothing cached. $ get-directory-name platinfo Linux64bit+2.6-2.12:slf6:x86_64 # Correct answer, but not cached. $ get-directory-name subdir slf6.x86_64 # Correct answer, but not cached. $ printenv CET_PLATINFO CET_SUBDIR # Still empty.Now set up
$ setup cetpkgsupport $ printenv CET_PLATINFO CET_SUBDIR Linux64bit+2.6-2.12:slf6:x86_64 slf6.x86_64 # Correct and cached. $ get-directory-name platinfo Linux64bit+2.6-2.12:slf6:x86_64 # Correct answer read from cache. $ get-directory-name subdir slf6.x86_64 # Correct answer read from cache.
Your other question re moving
get-directory-name into UPS will be addressed separately.
#4 Updated by Ron Rechenmacher 8 months ago
OK. Thanks. This all makes sense. It just seems that cetpkgsupport - as a product that ups depends on - is awkward.
Actually, I would say it's just wrong. UPS should be able to setup any product without depending upon another product specifically for help in the setup process. Can you see how this doesn't make sense!
In this case I would say that cetpkgsupport was getting in the way of UPS (or messing with UPS). And this is why the 2 questions are related. Maybe ups would know to unset the cache variables?
#5 Updated by Kyle Knoepfel 8 months ago
Ron, thanks for bringing this to our attention. I agree there can be improvements to the current system that would obviate the workarounds you're using. The practical consideration, however, is that UPS is being phased out. Making any changes to UPS requires an extremely high threshold, which is met only if what you need cannot be met by any other means.
Based on the above discussions, it appears that you have a way forward, even if it is icky and not to your liking. As SciSoft team leader, though, I cannot ask the cetpkgsupport and UPS maintainers to commit more of their time to this issue.
Thanks for your understanding, and I'm happy to follow up privately if you wish.