60 likes | 146 Vues
This system allows users to easily include default package versions in templates stored centrally. Changing default versions requires updating only one place, streamlining workflows. Utilize functions like pkg_add, pkg_repl, and pkg_del with specified arguments. Manage default values for versions and architectures efficiently. Automate template creation with RPMGetDefault.pl tool. Ensure accurate RPM splitting and version checks for software distribution tasks.
E N D
Package functions and tools in CDB Veronique LefebureGerman Cancio ELFms meeting 01.02.05
Idea • Give the possibility to include the default version of a package in a template • The default versions are centrally stored in a separate template • When the default version is changed (security upgrade, …): it is changed at one single place • See Savannah bug 5424 (04.11.04)
PAN functions • Pkg_add, pkg_repl, pkg_del: • Arguments: • <name> <version> <arch> <multi> • Now “DEF” is a possible value for <version> and for <arch> • The default values are found in pro_software_packages_defaults_<os>.tpl
Pro_software_packages_defaults_<os>.tpl • Define variable package_default = nlist(“name1”,list(“version1”,”arch1”),….“nameN”,list(“versionN”,”archN”) );
RPMGetDefault.pl • Creates pro_software_packages_defaults_<os>.tpl • `rpm -qp --nosignature --queryformat '%{NAME} %{VERSION}-%{RELEASE} %{ARCH}' $Source/$pack` • $Source = (configurable) • /afs/cern.ch/project/linux/cern/<os>/<arch>/Redhat/RPMS • /afs/cern.ch/project/linux/cern/updates/<arch>/RPMS
Manual steps left • CDB commit the new pro_sw_pkg_defaults_<os>.tpl • Check for new splitting of RPMs • Check (?) for hardcoded RPM versions