Skip to content

Instantly share code, notes, and snippets.

@chasinglogic
Last active January 9, 2020 20:40
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save chasinglogic/f922ef0702c7eb8b5f1330838cbd695b to your computer and use it in GitHub Desktop.
Save chasinglogic/f922ef0702c7eb8b5f1330838cbd695b to your computer and use it in GitHub Desktop.

Table of Contents

  1. Building packages at MongoDB
    1. Today's process:
      1. Adding a binary to the packages
        1. If it's a env.Library() or env.Program() call, like mongod
        2. If it's an external binary
        3. If it's a text file like a new LICENSE, config file, or man page
        4. If it needs to be in the tarball packages
        5. If it needs to be in the RPM packages
        6. If it needs to be in the Debian packages
        7. If it needs to be in the MSI package
    2. Generative Packaging Process:
      1. Adding a binary to the packages
        1. If it's an env.Library() or env.Program() call like mongod
        2. If it's an external binary
        3. If it needs to bin the tarball, RPM, Debian, or MSI packages

Building packages at MongoDB

Today's process:

Adding a binary to the packages

Additional consideration to all of these stages must be taken if the file is enterprise only and will then require changes to packager and packager_enterprise scripts. Since today neither of those scripts have access to the information SCons does and so have no way to know what files should go where / should be packaged.

If it's a env.Library() or env.Program() call, like mongod

  1. Regardless of where the corresponding code exists in the source tree the env.Program call must exist in src/mongo/SConscript
  2. Normalize the file name based on Platform using about 42 lines of Python
  3. Call env.Install specifying exactly where the binary should end up

If it's an external binary

  1. Inside src/mongo/SConscript
  2. Convert path to an env.File call
  3. Call env.Install specifying exactly where the binary should end up

If it's a text file like a new LICENSE, config file, or man page

  1. Inside src/mongo/SConscript
  2. Add it to the list of MODULEBANNERS via env.Append(MODULE_BANNERS=['path/to/my/new/doc/file'])

If it needs to be in the tarball packages

  1. Add to global variable inside SConscript distBinaries
  2. Verify there is a PostAction on posix systems to chmod the binary such that it is executable. (only needed for non env.Program/Library calls like the tools or install_compass)
  3. Add a corresponding --transform flag specifying the transformation the binary must undergo to end up in the correct final installed location.
  4. For example if you wanted to add liboplog.so to the tarball (ex. for a dynamic build) you would need to add: --transform $BUILD_DIR/mongo/db/repl=$SERVER_DIST_BASENAME/lib
  5. If the path of the source code (and therefore the output binary) changes you also make sure to keep this list of strings up to date with changes in any other SConscripts

If it needs to be in the RPM packages

  1. Follow the steps for adding to tarball packages, this package is dependent on the existence of the binaries in the tarball.
  2. Add the binary to the list of files installed under %{_bindir} in the spec file
  3. Add any documentation or text files to the appropriate location in the spec file
  4. Repeat steps 2 and 3 for all TEN spec files
  5. Additionally, if generating a new package wire up dependencies manually in all ten spec files.

If it needs to be in the Debian packages

  1. Follow the steps for adding to tarball packages, this package is dependent on the existence of the binaries in the tarball.
  2. Add a cp -v $(CURDIR)/path/to/my/file /debian/package-name/installed/location command to the install section of the rules file
  3. Add a corresponding rm command line to the clean section of the rules file.
  4. Repeat steps 2 and 3 for all FOUR rules files.
  5. Additionally, if generating a new package wire up dependencies manually in all four Debian control files.

If it needs to be in the MSI package

  1. Add a Component tag in BinaryFragment.wxs
  2. Add an appropriate file tag to the Component tag specifying the complete path to your binary
  3. Make sure they have unique Id and Guid fields
  4. Set any other fields as required for WIX integration
  5. Create a Feature tag in FeatureFragment.wxs
  6. Create ComponentRef tags to point the feature to your Component's

Generative Packaging Process:

Adding a binary to the packages

If it's an env.Library() or env.Program() call like mongod

  1. Wherever you have made the env.Program call add the keyword argument COMPONENT_TAG='mycomponent' and the file will be packaged and installed into the correct packages with package dependency tracking.

If it's an external binary

  1. Call env.AutoInstall with the target='$INSTALL_DIR/bin and source=['pathtofile'] and the keyword argument COMPONENT_TAG='mycomponent' and the file will be packaged and installed into the correct packages with package dependency tracking.

If it needs to bin the tarball, RPM, Debian, or MSI packages

  1. Nothing further required.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment