Hi,
I initially intended to write this eMail as a follow-up to another thread on the mailing list: [X2Go-Dev] FYI: I updated the Fedora Rawhide mock files onjenkins
However, this turns out to be a bad idea as the changes to the buildscripts were quite massive and not just fixing one issue.
Thus, I'll be utilizing this to give you all a summary of what changed.
Deb + RPM shared changes: o New cleanup mechanism. Temporary directories are now always deleted, no matter whether the build was successful or not. o Added a lot of quotes and put variables in ${CURLY_BRACES}. o Functions are, whenever possible, not ran in subshells. This means that global variables can be modified and will actually have an effect in the main process. o Lots of small improvements, for instance by not using echo "${var}" | grep "searchstr", but grep "searchstr" <<< "${var}" or grep "searchstr" "file" instead of cat "file" | grep "searchstr"
RPM changes: o New mock config file creation mechanism for merging a base mock config with a .repo file. o New option "RPM_MOCK_CONFIG_DIR". Default: /etc/mock. Not overridden in x2go.conf. Specifies the location of mock .cfg and additional .repo files. o New option "RPM_EXTRA_REPO_MOCK_CONFIG_BASE". Default: empty string. Overridden in x2go.conf to "x2go". Sets the prefix for .repo files in the ${RPM_MOCK_CONFIG_DIR} directory. (hell, I should probably change this to a better, shorter name, but I have no idea to what exactly...) o New option "RPM_WANT_EXTRA_REPOS". Default: 0. Overridden in x2go.conf to 1. If this is enabled, additional repositories provided in ${RPM_MOCK_CONFIG_DIR} are taken into account and merged with the base mock config file. Otherwise, the default config files in /etc/mock will be used by running mock with the option -r ${DISTRIBUTION}-${VERSION}-${ARCH}, e.g. -r fedora-22-x86_64. o Additional repository files in ${RPM_MOCK_CONFIG_DIR} have to follow this naming convention: ${RPM_EXTRA_REPO_MOCK_CONFIG_BASE}-${DISTRIBUTION}.repo and should contain: - a section called ${RPM_EXTRA_REPO_MOCK_CONFIG_BASE}- -extras-${DISTRIBUTION}.
Example for X2Go and EPEL:
[x2go-extras-epel]
- a section called ${RPM_EXTRA_REPO_MOCK_CONFIG_BASE}-
-release-${DISTRIBUTION}
Example for X2Go and Fedora:
[x2go-release-fedora]
- a section called ${RPM_EXTRA_REPO_MOCK_CONFIG_BASE}-
-nightly-${DISTRIBUTION}
Example for X2Go and EPEL:
[x2go-nightly-epel]
Each of these section should contain at least the following keys
(but they are currently not enforced to be present):
- name
- baseurl
- enabled
- gpgkey
- gpgcheck
For all packages, the extras section will be copied to the
generated temporary mock config file.
If the package to be built is NOT included in the list provided by
the already existent ${PACKAGE_WITHOUT_OTHERMIRROR} variable, the
release or nightly section will also be copied to the generated
temporary mock config file.
For all copied sections, the "enabled" key will be forcefully set
to 1 and "gpgcheck" to 0. I may change the latter behavior at a
convenient time with prior testing.
/etc/mock changes: o Copied /etc/mock to /etc/mock-2015-04-03 as a backup. o Copied original .cfg files to .cfg.orig. o Fetched new .cfg files from mock's upstream git archive for version 1.2.7. o For Fedora 20 to 22, the upstream config files define "releasever" and use it as a variable in the yum.conf section. This does not work with mock 1.1.33. Thus I copied the original upstream files with an .upstream suffix and used sed to hardcode the release version in the "normal" mock config files.
If this was all too verbose, (anyone) please tell me.
Mihai
I forgot to mention a few things.
The changes are in production now and used by Jenkins.
Tests by building x2goserver look successful.
The caveat of generating temporary mock files on demand by merging our custom x2go repo files with the mock base config is that every time mock is executed the root cache is being regenerated, resulting in a performance impact of about 10%. This said, build times aren't exactly deterministic and specific build time overheads may deviate from 5% to 30%.
This isn't too bad, though, and I may implement caching of generated mock config files at a later date, probably some time later in April.
Mihai