Proposal to Separate Existing Single PKI Source Repository into Multiple PKI Source Repositories

From Dogtag
Revision as of 19:44, 8 November 2017 by Mharmsen (talk | contribs) (Disadvantages)

Jump to: navigation, search

Overview

Currently, the PKI repository (git@github.com:dogtagpki/pki.git) consists of source code which is utilized to build the following four SRPMS:

  • dogtag-pki
    • NOTE: This 'meta' package only contains a spec file (no tarball since it does not consist of any source).
  • dogtag-pki-theme
    • SOURCE CODE: pki/dogtag/
  • pki-console
    • SOURCE CODE: pki/base/console/
  • pki-core
    • SOURCE CODE: pki/base/ (with the exception of 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):

  • pki/scripts/compose_dogtag_pki_meta_packages
    • NOTE: RPM and SRPM only -- no tarball
  • pki/scripts/compose_dogtag_pki_theme_packages
  • pki/scripts/compose_pki_console_packages
  • compose_pki_core_packages

Proposal

This proposal is to separate this single PKI source repository into four distinct source repositories:

  • pki-meta
    • SOURCE CODE: This 'meta' directory contains local development scripts and spec file templates (pki/scripts/ and pki/specs/) and can be checked out in tandem with other PKI repos using 'git clone git@github.com:dogtagpki/pki-meta.git pki'.
  • pki-theme
    • SOURCE CODE: pki/dogtag/
  • pki-console
    • SOURCE CODE: pki/base/console/
  • pki-core
    • SOURCE CODE: pki/base/ (with the exclusion of pki/base/console/)

Each of these four repositories could be created to preserve existing by doing something like the following (e. g. - 'pki-meta'):

  • git clone git@github.com: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"

Advantages

  • 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.
  • To assist in local development, the original all-encompassing repo could still be recreated by merely checking out directories which cleanly overlay each other:
 # git clone git@github.com:dogtagpki/pki-meta.git pki
 # git clone git@github.com:dogtagpki/pki-theme.git pki
 # git clone git@github.com:dogtagpki/pki-core.git pki
 # git clone git@github.com:dogtagpki/pki-console.git pki

Disadvantages

  • 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.