Proposal to Separate Existing Single PKI Source Repository into Multiple PKI Source Repositories
Currently, the PKI repository (firstname.lastname@example.org:dogtagpki/pki.git) consists of source code which is utilized to build the following four SRPMS:
- NOTE: This 'meta' package only contains a spec file (no tarball since it does not consist of any source).
- SOURCE CODE: pki/dogtag/
- SOURCE CODE: pki/base/ (with the exception of pki/base/console)
- SOURCE CODE: pki/base/console/
Due to this layout, we need to utilize the various 'compose' scripts to create local RPMS and the various 'tarballs' for use in the SRPMS (some of which become 'official' tarballs):
- NOTE: RPM and SRPM only -- no tarball
Additionally, if Quality Engineering (QE) would like tests separated, the following additional repo could be created:
- SOURCE CODE: pki/tests/
This proposal is to separate this single PKI source repository into four distinct source repositories:
- SOURCE CODE: This 'meta' directory contains local development scripts and spec file templates (pki/scripts/, pki/specs/, and pki/tools/) and can be checked out in tandem with other PKI repos using 'git clone email@example.com:dogtagpki/pki-meta.git pki'.
- SRPM: dogtag-pki
- SOURCE CODE: pki/dogtag/, pki/cmake/, pki/patches/, and pki/tests/
- SRPM: dogtag-pki-theme
- SOURCE CODE: pki/base/ (with the exclusion of pki/base/console/, pki/cmake/, pki/patches/, and pki/tests/
- SRPM: pki-core
- SOURCE CODE: pki/base/console/, pki/cmake/, pki/patches/, and pki/tests/
- SRPM: pki-console
Each of these four repositories could be created to preserve existing by doing something like the following (e. g. - 'pki-meta'):
- git clone firstname.lastname@example.org:dogtagpki/pki.git pki-meta
- remove everything EXCEPT the two directories pki/scripts/ and pki/specs/
- check in the new github repo as "dogtagpki/pki-meta.git"
- With this separation of source, it would now be possible to create full-source tarballs using standard methods (e. g. - git archive).
- This would open up the possibility to use tools such as Tito in COPR to create builds by merely pointing to a repository.
- The various tarballs would contain source code that is only relevant to the RPMS produced for that SRPM (i. e. - "clean" un-polluted source and no spec file template confusion).
- To assist in local development, it "may" be possible that the original all-encompassing repo could still be recreated by merely checking out directories which cleanly overlay each other:
# git clone email@example.com:dogtagpki/pki-meta.git pki # git clone firstname.lastname@example.org:dogtagpki/pki-theme.git pki # git clone email@example.com:dogtagpki/pki-core.git pki # git clone firstname.lastname@example.org:dogtagpki/pki-console.git pki NOTE: One issue with this may be the common pki/cmake/ directories, common files within the pki/tests/ directory, common top-level files, etc.
- Continuous integration (CI) tools such as Travis may need to be replicated across multiple repositories (pki-theme, pki-core, and pki-console)
- Potential conflicts could arise with check-ins being required in two separate repositories (e. g. - pki-core and pki-console, or pki-theme and pki-console)
- Version mismatch may arise more easily in this model (e. g. - pki-server 10.7.0 and pki-console 10.6.1) making it more difficult on dependency tracking.
- The pki/cmake/ directory and associated common top-level files may need to be replicated in multiple repositories.
- The pki/tests/ directory may need to have common portions replicated across multiple repositories.