Other content types in BDCS
The main difference between RPM imports and everything else is that RPM describes an exact mapping from data to filesystem, while source-based registries, such as npm, pip, hackage, or gem, do not. Even for languages that are not compiled, there needs to be a “build” step to translate the source archive paths to their final form.
The import/export process we currently have for RPM is, roughly:
- Unpack the RPM into the content-store
- Map the RPM files to a
groupsrecord in the mddb
- Save the dependencies in
requirementsin the mddb
- Select a
groupsbased on a recipe
- Depsolve the
requirementsto pull in other necessary groups
- Write all of the groups’ files to the new filesystem.
Modifying this process for source-based archives looks something like:
- Import the source archive into the content-store
- Map the source files to a
sourcesrecord in the mddb
- Store the build dependencies for the source
- Depsolve a recipe request into a set of packages and requirements
- Look for builds satisfying the requirements
- Build and cache any missing requirements
- Write the builds’ files to the new filesystem.
The npm import/export, once complete, will give us an idea of how welder can combine RPM data with data from other package registries, as well as how modularize registry-specific logic within bdcs. Stay tuned to this space for more, or join us on IRC or github.