APT, Yum, Raw, RubyGems, Composer, and Operating-System or Generic Artifact Formats: Concepts, Architecture, and Mental Model

1. The practical problem: “a package repository” is not one protocol

In Chapters 06–10, each ecosystem had its own client protocol. This chapter makes the contrast explicit. A Debian client does not discover .deb files by browsing arbitrary URLs. It reads APT metadata that describes distributions, package names, versions, dependencies, architectures, hashes, and file locations. A Yum/DNF client uses RPM repository metadata under repodata/. RubyGems expects gem indexes and gem metadata. Composer v2 resolves PHP packages through Composer metadata. A Raw repository, by design, supplies none of those package-manager semantics.

The operational consequence is important: if you place a valid package file into the wrong repository format, the bytes may be downloadable while the package manager still cannot resolve, verify, update, or select them correctly. The server may be healthy; the protocol model is wrong.

2. Current repository-type matrix

The matrix itself is not the lesson. The reason APT lacks a group while Yum/RubyGems/Raw have one is that each format requires implementation-specific aggregation semantics. Never infer group support just because another format has it.

3. APT: package files, distributions, indexes, and metadata signatures

APT repositories expose Debian-family packages through a structured repository. A hosted APT repository requires a distribution and signing configuration. Nexus generates repository metadata from uploaded packages and signs the metadata; it does not sign the individual .deb packages for you. Package signing and repository-metadata signing are distinct trust controls.

APT proxy repositories can either pass upstream metadata through or, when configured appropriately, regenerate/re-sign metadata for a configured distribution. The client must use the distribution that matches the repository configuration. An incorrect distribution can look like a “404 problem” even though Nexus itself is reachable.

4. Yum/RPM: repodata, RPM signatures, and repository metadata signatures

A Yum repository contains RPM packages plus generated repository metadata such as repodata/repomd.xml. Hosted repositories have a Repodata Depth setting that determines where Nexus creates metadata and the minimum path depth accepted for uploaded RPMs. Proxy and group repositories can be configured with a GPG key so Nexus signs the metadata it generates.

Again, Nexus signing repository metadata does not sign the RPM package. The package build/publishing pipeline is responsible for RPM signing if package-signature verification is required. A DNF/Yum client can independently enforce repo_gpgcheck for metadata and gpgcheck for packages.

5. RubyGems: name/version identity plus generated repository information

RubyGems packages are .gem files containing code and gem metadata. Nexus identifies a RubyGems component by name and version. Hosted repositories are authoritative for private gems, proxies cache remote gems such as those from rubygems.org, and a group can expose hosted plus proxy content at one URL. Group member order matters when the same package/version appears in more than one member.

The native client adds another state layer: RubyGems has configured sources and local cache/install locations. A successful gem install may be satisfied from local client state unless you deliberately isolate or clear it during a diagnostic.

6. Composer: current support is v2-only and version-sensitive

Nexus native Composer proxy support appeared in 3.75.0; hosted and group repositories arrived in 3.95.0. Current Composer documentation states that Nexus supports the Composer v2 protocol only; a remote repository that exposes only Composer v1 metadata cannot be proxied successfully.

Composer also has its own public fallback behavior: Packagist is enabled by default unless explicitly disabled. An organization intending Nexus-only resolution must configure Composer so it does not silently bypass the repository boundary.

7. Raw: useful precisely because it has no package-manager semantics

Raw repositories provide HTTP-like paths for arbitrary files: CLI installers, firmware bundles, static websites, release manifests, checksums, exported reports, or generic ZIP/TAR archives. Nexus treats every Raw file as a separate component; it does not infer a package family or group related files into one logical package.

This makes Raw a good match when the consumer already knows the exact path and does not need native dependency resolution. It makes Raw a poor match for .deb, RPM, gem, or Composer packages when you expect the package manager to discover versions, dependencies, indexes, or trust metadata.

8. Five trust layers that are often confused

9. Read-only inspection before mutation

export NX_URL="http://127.0.0.1:8081"
export LAB="${TMPDIR:-/tmp}/nexus-ch11"
rm -rf "$LAB"
mkdir -p "$LAB/evidence"
chmod 700 "$LAB"

curl -fsS "$NX_URL/service/rest/v1/status"   | tee "$LAB/evidence/status.txt"
curl -fsS "$NX_URL/service/rest/v1/repositories"   | tee "$LAB/evidence/repositories-before.json"

Record the actual version/edition from the UI as well. If the lab already contains APT, Yum, Raw, RubyGems, or Composer repositories, inspect their type, blob store, online status, and format-specific fields before creating anything.

10. Why this matters in DevOps

Repository-format fidelity turns a file server into an operational package boundary. Native formats let package managers resolve the metadata they understand; Raw gives operations teams a controlled place for artifacts that do not need a package protocol. The correct format reduces bypasses, ambiguous paths, manual installation steps, and home-grown metadata generation.

11. Common wrong mental models

• “If the file downloads, the repository format is correct.” Downloadability is weaker than package-manager compatibility.
• “APT and Yum signing are the same.” Their metadata structures and client trust configuration differ.
• “Nexus signs packages when it signs repository metadata.” It does not.
• “Every native format supports group.” APT currently does not.
• “Raw is universal, so native formats are optional.” Raw is universal only at byte/path transport, not package semantics.
• “Composer support is timeless.” Native proxy, hosted, group, protocol, and edition boundaries changed across releases.

Knowledge check

12. Summary and next step

Native formats are contracts, not filename categories. APT, Yum, RubyGems, Composer, and Raw differ in index generation, trust roots, client configuration, and repository-type support. The operator's first job is to identify the client protocol and expected metadata before creating a repository.

Lesson 2 turns that model into a controlled multi-format lab with a native RubyGems path and a generic Raw path.

Official references and version notes

• Sonatype: Formats — current proxy/hosted/group support matrix.
• Sonatype: APT Repositories.
• Sonatype: Yum Repositories and GPG signatures for Yum.
• Sonatype: Raw Repositories.
• Sonatype: RubyGems Repositories.
• Sonatype: Composer Repositories.
• Sonatype: Components API — APT, Raw, and RubyGems upload field names.
• Sonatype: Community/Pro feature matrix and Community Edition onboarding.
• Sonatype: 2026 self-hosted release notes.
• RubyGems command reference, Composer documentation, and distribution-specific APT/DNF/RPM documentation for client trust configuration.

Version-sensitive statements were rechecked on 2026-08-26. The chapter uses Nexus Repository 3.95.0 as the verified feature floor because current Sonatype release notes explicitly list it as released on 2026-08-05 and document Composer hosted/group support there. Some adjacent Sonatype download/version-status pages still lag at 3.94.1, so record the exact version/edition on your lab instance before applying version-specific steps. If you are continuing with a later 3.95.x instance from a prior chapter, it satisfies this chapter's 3.95.0 feature floor. Mandatory labs use Community-compatible RubyGems and Raw features and do not depend on the documentation-sensitive Composer entitlement boundary.