Curated Bioconductor Sources

EnhancedAdvanced

A curated Bioconductor source serves a subset of Bioconductor that you choose and validate, instead of the full mirror. This is especially useful in secure, regulated environments, where only approved sets of packages are allowed.

Bioconductor publishes numbered releases twice a year, generally in April and October, and each package version belongs to one release. A curated Bioconductor source follows that structure. Rather than holding one curated set pinned to one snapshot date, it holds one curated set per Bioconductor release, each with its own snapshot date, its own list of packages, and its own R version. You can therefore validate Bioconductor 3.22 and Bioconductor 3.23 on different timelines within a single source.

If you are familiar with curated-cran sources, that difference is the main one to keep in mind. Almost every command on this page takes a --bioc-version flag naming the release it applies to. Throughout this page, a “Bioconductor version” of a curated source means that source’s curated set for that release, not the upstream release itself.

A curated Bioconductor source holds Bioconductor packages only. R clients resolve CRAN dependencies at install time from a CRAN repository, which is either the same repository or a separate one depending on the repository type you serve the curated source from. See Pairing with a CRAN Source.

Creating a Curated Bioconductor Source

rspm create source creates a curated Bioconductor source with no versions in it. It takes no snapshot, no include list, and no other configuration at creation time, because those settings belong to individual Bioconductor versions. For the same reason it rejects --snapshot, --include, and --no-archived for a curated-bioconductor source. It also rejects --strict, because curated Bioconductor has no strict mode. See Strict Curated CRAN for what that mode does.

Terminal
rspm create source --name=validated --type=curated-bioconductor
Output
Source 'validated':
  Type:  Curated Bioconductor

Once the source exists, subscribe a repository to it to make the packages available to users. How the packages are served depends on the type of repository you subscribe, so read Serving Curated Bioconductor Packages before subscribing.

Including Packages in a Bioconductor Version

Include packages by uploading a requirements.txt definition with rspm update, one Bioconductor release at a time. Name the release with the --bioc-version flag.

WarningCurate only releases the server has enabled

Check this before your first update. The Bioconductor.EnabledVersions setting restricts which Bioconductor releases the server knows about. Curating a release that setting excludes is not blocked at update time, but the release is missing from the manifest the server validates against, so parts of the interface reject it later. Its Activity Log, for instance, reports invalid Bioconductor version.

If you set EnabledVersions, include every release you intend to curate.

Terminal
rspm update --source=validated --bioc-version=3.23 --file-in=/path/to/requirements.txt --snapshot=2026-08-22 --commit

rspm update makes every change to a curated Bioconductor source, including the first one. There is no separate command to add a Bioconductor version, and rspm add does not work against this source type. The first time you update a release, Package Manager creates the version. New upstream Bioconductor releases do not extend the source on their own, so you decide which releases the source covers by choosing which ones to update. Only one release can be named per command, so to cover several, run the command once for each.

Requirements Files

Curated Bioconductor uses the same requirements.txt format as curated-cran, with one addition, the optional marker:

Curated Bioconductor Requirements Format
[package name] [optionally: version constraints] [[optionally: extras]] [optionally: ; marker]

List only Bioconductor packages. R clients resolve CRAN dependencies at install time from a CRAN repository, so CRAN packages do not belong in a curated Bioconductor requirements file.

Two things control which related packages come along with a package: a file-level --include directive, which sets the default for every package in the file, and a per-package extras block, which widens that default for one package.

Write the directive on a line of its own, before or among the package lines:

requirements.txt
--include imports,depends,linking-to

limma [suggests]
BiocGenerics

Here BiocGenerics gets the three types the directive names, and limma gets those plus suggests.

Without a directive a curated Bioconductor version starts from imports, depends, and linking-to. The valid values are the same as for the curated CRAN --include flag, including none:

requirements.txt
# Take only what each package strictly needs, then widen one package:
--include none

limma [imports]

--include is the only way to set the default for a curated Bioconductor version, because the source-level --include flag on rspm create source applies to curated CRAN sources only. It may appear once per file. An unusable value fails the update rather than being ignored.

Extras add to the default and never narrow it, so a package’s [extras] block can only widen what the directive set. To narrow, lower the directive.

The requirements file describes the whole selection, so change the line to change it, and delete the line to go back to the default. A snapshot-only refresh keeps whatever the last file you committed said, because it re-reads that file.

A dry run previews the file you give it, so a change to --include shows up in the preview along with the packages it adds or removes.

NoteSharing a requirements file with the offline downloader

rspm-offline-downloader reads the same directive, so a file that sets --include works with both. It also reads --since, which windows an offline download and means nothing to a curated source; an update accepts that line and reports that it had no effect. Any other directive is an error. The downloader’s platform selectors are command flags rather than file directives, so they do not belong in this file either.

The two tools differ on one point. The downloader treats a package’s [extras] block as a replacement for the default, where Package Manager treats it as an addition, so a package that carries both a directive and its own extras resolves to a different set in each. A file whose packages carry no extras means the same thing to both.

Because one source covers several Bioconductor releases, it is often convenient to keep a single requirements file and let each line declare which releases it applies to. That is what the marker is for. Add it after a semicolon:

requirements.txt
# Applies to every Bioconductor version:
limma
BiocGenerics

# A different pinned version per release:
DESeq2 ==1.50.2; bioc_version == "3.22"
DESeq2 ==1.52.0; bioc_version == "3.23"

# Only from 3.22 onward:
Heatplus; bioc_version >= "3.22"

When you update a Bioconductor version, Package Manager drops the lines whose marker excludes that release before resolving the packages. Updating 3.22 with the file above requests limma, BiocGenerics, DESeq2 ==1.50.2, and Heatplus. Updating a hypothetical 3.21 would request only limma and BiocGenerics.

Markers support the comparison operators ==, !=, >=, <=, >, and <, with values in either single or double quotes. Package Manager compares versions numerically rather than as text, so bioc_version >= "3.9" correctly includes 3.22. Combine multiple clauses on one line with and:

requirements.txt
DESeq2; bioc_version >= "3.22" and bioc_version < "3.24"

Package Manager rejects the or operator and the set operators in and not in, and a malformed marker fails the update rather than passing unnoticed.

Only curated Bioconductor sources recognize markers. A curated-cran or curated-pypi update strips and ignores a marker, so the same file applied to those source types requests every line.

Updating a Bioconductor Version

An update takes a requirements file, the Bioconductor release, and a Bioconductor snapshot date. Run it without --commit first to preview the changes:

Terminal
rspm update --source=validated --bioc-version=3.23 --file-in=/path/to/requirements.txt
Output
Packages from '/path/to/requirements.txt' to update source 'validated' for Bioconductor 3.23 (R 4.6) at snapshot date '2026-08-22':

Name                 Version Action Needs Compilation Dependency
Biobase              2.72.0  add    yes               true
BiocGenerics         0.58.1  add    no                false
BiocParallel         1.46.0  add    yes               true
DESeq2               1.52.0  add    yes               false
Heatplus             3.20.0  add    no                false
IRanges              2.46.0  add    yes               true
S4Vectors            0.50.1  add    yes               true
<truncated>
limma                3.68.5  add    yes               false

If the output above looks correct, execute this command again with the --commit and --snapshot=2026-08-22 flags to update the source with the new set of packages.

Dependency false marks a package your requirements file named. Dependency true marks one Package Manager added to satisfy a dependency.

--snapshot is optional on a dry run and required to commit. Omit it on a dry run and Package Manager uses the latest snapshot available for that Bioconductor release, which is the final state for an archived release and the current state for the release still in development. Committing without --snapshot fails, so that a committed version always records the exact snapshot you validated it against.

To commit the changes, repeat the command, adding the --commit and --snapshot flags:

Terminal
rspm update --source=validated --bioc-version=3.23 --file-in=/path/to/requirements.txt --snapshot=2026-08-22 --commit

Repeat it for each Bioconductor release the source should cover:

Terminal
rspm update --source=validated --bioc-version=3.22 --file-in=/path/to/requirements.txt --snapshot=2026-01-15 --commit
rspm update --source=validated --bioc-version=3.23 --file-in=/path/to/requirements.txt --snapshot=2026-08-22 --commit

Each release takes its own --snapshot. That is the point of the per-version design. You validate each release against the snapshot you tested it at, on its own schedule.

Warningrspm update replaces a version’s contents

Running rspm update with a requirements file replaces that Bioconductor version’s contents with only the packages that file resolves to. It does not affect any other version.

To move a Bioconductor version to a newer snapshot without changing which packages it requests, omit --file-in:

Terminal
rspm update --source=validated --bioc-version=3.22 --snapshot=2026-04-09 --commit

Package Manager carries the version’s committed requirements forward and resolves them again at the new snapshot. The requirements are what is preserved, not the resolved package set. Dependencies can appear or disappear between snapshots, so review the preview before committing.

Inspecting Curated Versions

To see which Bioconductor versions a source curates and how each is configured, run rspm list sources with the --name and --details flags:

Terminal
rspm list sources --name=validated --details
Output
Curated Bioconductor versions for source 'validated':

Bioconductor Version  R Version  Dependencies  Snapshot    Last Updated
3.22                  4.5                      2026-04-09  2026-04-09 11:00:19
3.23                  4.6                      2026-08-22  2026-08-22 09:14:52

The table lists the versions the source offers, so a version you have removed does not appear. Dependencies reports the version’s dependency selection, which is the --include directive its requirements file set. It is empty for a version whose file sets none, which means the version uses the default of imports, depends, and linking-to rather than that it pulls in no dependencies. This column does not report per-package extras. If the source curates no versions at all, the command reports that instead of printing a table.

The table reports configuration rather than contents, so it shows no package count. To list the packages a version curates, use rspm list packages with the source name and the version:

Terminal
rspm list packages --source=validated --version=3.23

Serving Curated Bioconductor Packages

Subscribe a curated Bioconductor source to either an R repository or a Bioconductor repository. The two serve the curated packages at different URLs and suit different purposes. The examples below continue with the validated source created above.

A repository can hold at most one Bioconductor-family source. Package Manager rejects a second curated Bioconductor source, and it does not mix mirrored Bioconductor content with curated Bioconductor content in one repository. To serve both a curated set and the full mirror, use two repositories.

In an R Repository

Subscribing a curated Bioconductor source to an R repository pins the repository to one Bioconductor release, which you name with --bioc-version:

Terminal
# Create an R repository:
rspm create repo --name=validated-r --type=r --description='CRAN plus validated Bioconductor packages'

# Subscribe it to one Bioconductor version of the curated source:
rspm subscribe --repo=validated-r --source=validated --bioc-version=3.23

# Subscribe a CRAN source to the same repository, to satisfy CRAN dependencies:
rspm subscribe --repo=validated-r --source=cran

The repository then serves that version’s packages in the same flat PACKAGES file as its other R packages, alongside CRAN, curated CRAN, and local packages:

/validated-r/latest/src/contrib/PACKAGES

To serve Linux binaries, add the environment segment directly after the repository name:

/validated-r/__linux__/noble/latest/src/contrib/PACKAGES

This arrangement suits users who want a single repository URL that covers both CRAN and a validated set of Bioconductor packages, and who do not need more than one Bioconductor release.

The --bioc-version value is checked against the source’s own committed versions rather than against the full list of Bioconductor releases. Naming a release the source does not curate is rejected, and the error lists the versions that are available.

An R repository’s Setup page has no Bioconductor version selector and generates no BioC_mirror or BIOCONDUCTOR_CONFIG_FILE. Those settings are for BiocManager, which chooses a release, and this repository serves exactly the one release you subscribed. The page generates the ordinary install.packages snippet instead, carrying the repository URL and, if you choose a date, a snapshot segment.

When an R repository subscribes both a curated Bioconductor source and a mirrored CRAN source, the CRAN source contributes snapshot dates reaching back years before the curated Bioconductor version’s first commit. The Setup page’s calendar withholds those earlier dates, because a URL pins every source or none, and the curated version has no state to pin them to.

In a Bioconductor Repository

Subscribing a curated Bioconductor source to a Bioconductor repository serves every committed version, with the Bioconductor version taken from the request URL. Because the version comes from the URL, rspm subscribe rejects --bioc-version:

Terminal
# Create a Bioconductor repository:
rspm create repo --name=validated-bioc --type=bioconductor --description='Validated Bioconductor packages'

# Subscribe it to the curated Bioconductor source:
rspm subscribe --repo=validated-bioc --source=validated

The repository then serves the curated subset at the usual Bioconductor URLs, with the release version as a path segment:

/validated-bioc/packages/3.23/bioc/src/contrib/PACKAGES
/validated-bioc/packages/3.23/data/annotation/src/contrib/PACKAGES
/validated-bioc/packages/3.23/data/experiment/src/contrib/PACKAGES
/validated-bioc/packages/3.23/workflows/src/contrib/PACKAGES
/validated-bioc/config.yaml

To serve Linux binaries, add the environment segment directly after the repository name, before the transaction segment. The Bioconductor version stays where it is, so the two segments do not sit next to each other:

/validated-bioc/__linux__/noble/latest/packages/3.23/bioc/src/contrib/PACKAGES

Putting __linux__ after the version instead returns a 404.

Both the source and the binary URL serve a file named .tar.gz, so the URL does not tell you which one a client received. The install log does: a binary install reports * installing *binary* package, and on Windows successfully unpacked and MD5 sums checked. The server’s access log shows which URL the client actually requested.

One curated version covers all four Bioconductor sub-repositories. You curate a set of packages for a release, and the repository serves each package under whichever sub-repository Bioconductor publishes it in.

A Bioconductor repository serves mirrored Bioconductor content until a curated Bioconductor source is subscribed to it. After that it serves only the curated subset, and the mirrored content is no longer available through it. Unsubscribing the source restores the mirrored content.

Requesting a Bioconductor version the source has not curated returns a 404 that names the versions the URL does serve:

Output
Bioconductor version 3.20 is not served by this URL. Versions served here: 3.22, 3.23.

An undated URL serves each version’s current committed state. To pin to an earlier state, use a frozen snapshot URL, the same way you would with any other source. There are two ways to obtain one:

  • The Setup page, where you choose a Bioconductor version and then a date, and the URL it generates serves the state that version held on the date you pick. The version selector appears only on a Bioconductor repository’s Setup page, because only this repository type serves more than one release.

    The calendar offers the dates on which you committed that version, not the Bioconductor snapshot dates those commits recorded. The two are easy to confuse and they are rarely the same. Committing Bioconductor 3.22 with --snapshot=2026-04-09 on 28 August 2026 puts 28 August in the calendar and not 9 April, because the URL pins a transaction rather than a date, and the transaction is the update you ran. Looking for the snapshot date in the calendar and not finding it is expected. The Snapshot column of rspm list sources --name=<source> --details shows the Bioconductor snapshot date each version records, and the Last Updated column shows when you committed it.

  • Each dated row in a package’s history, which carries the frozen URL that serves that state.

Unlike mirrored Bioconductor repositories, a curated Bioconductor repository does not accept a bare date in place of a frozen snapshot URL. Both URLs above address a transaction instead of a date, so they keep serving a version after you remove it from the source. A bare date returns a 404 explaining which repositories accept one:

Output
invalid transaction alias 2026-08-28; date aliases require a repository subscribed to exactly one mirrored CRAN, Bioconductor, or PyPI source. Curated sources and other source types are pinned with a snapshot URL from the repository's Setup page instead

Only a mirrored CRAN, Bioconductor, or PyPI source carries date aliases. You pin every other source type, including all of the curated types, with a snapshot URL.

R does not show that message to the user. It discards the response body and reports package 'BiocGenerics' is not available for this version of R instead, which names neither the cause nor the fix. On Windows, R also emits unable to access index for repository <full URL>, and that line is the useful one. Request the URL it names directly, with curl or a browser, to read the server’s own message.

A frozen snapshot URL serves only the Bioconductor version it was created for. Requesting another version through it returns the same 404, naming only that one version as served there. The repository can still offer the other version at an undated URL.

The config.yaml served at a frozen snapshot URL follows the same scoping. It names the pinned release, and every other release in its version map carries a placeholder R version that no real R matches.

One consequence is worth knowing about before it looks like a defect. Only the pinned release keeps a real R version, so it is the highest R version the document names. BiocManager also considers one R version above the highest it finds, paired with the highest Bioconductor release in the map. A client running that newer R therefore selects a release the frozen snapshot URL does not serve.

The failure happens before the client requests any package. BiocManager reports that the release it selected requires the placeholder R version, so the message names a version no client runs. The remedy that message suggests does not help, because the release it selected is not one this URL can serve. Run the R version the pinned release was built for, or use an undated URL instead.

This affects BiocManager only. install.packages takes the release from the URL path rather than from a version map, so it installs from a frozen snapshot URL whatever R version is running.

Removing a Bioconductor Version

A single Bioconductor version can be removed without disturbing the ones the source keeps. Removal uses the same rspm update command as every other change to a curated source, with --remove, and follows the same preview-then-commit pattern:

Terminal
# Preview the removal
rspm update --source=validated --bioc-version=3.22 --remove
Output
Bioconductor 3.22 (snapshot 2026-04-09) would be removed from source 'validated'.

The version stops being offered, and repositories subscribed to this source stop
serving it. Frozen snapshot URLs created before the removal continue to work, and
no package files are deleted.
If the output above looks correct, execute this command again with the --commit flag.
Terminal
# Remove it
rspm update --source=validated --bioc-version=3.22 --remove --commit
Output
Removed Bioconductor 3.22 from source 'validated'.

The preview checks the current source state and reports the expected effect. It performs every check the removal does, but the source can change between the two commands, so run the removal against a preview you have just taken.

A removal is a new commit rather than a deletion, in the same way that removing a package from a curated CRAN source commits a set without it. The version stops being offered from that commit onward, and everything committed earlier is untouched. A frozen snapshot URL captured before the removal keeps serving exactly what it served before, including the removed version, and the dated rows in a package’s history keep working whether or not the repository is still subscribed to the source. A config.yaml requested at that same frozen URL also keeps describing the removed version, so a BiocManager client pinned there can still install the release it was using.

What a subscribed repository serves at its undated URLs depends on its type:

  • A Bioconductor repository takes the release from the request URL and serves every committed version, so it simply stops offering the removed one. A request for it returns a 404 naming the versions that remain, and BiocManager can no longer select it from the repository’s config.yaml.
  • An R repository subscribes with --bioc-version and is bound to exactly one version, so its flat PACKAGES index stops listing that version’s packages. Its URL carries no Bioconductor version, so there is nothing for Package Manager to return a 404 on, and the index is simply shorter. Because that change is invisible to clients, both the preview and the removal name the affected repositories:
Output
Repo(s) 'validated-r' are pinned to this version and would stop serving its packages.
Frozen snapshot URLs created before the removal continue to work.

To keep such a repository serving Bioconductor packages, move it to another version. rspm subscribe cannot re-point an existing subscription, because a repository can subscribe to a given source only once and the command reports that it is already subscribed. Unsubscribe the source first, then subscribe again with the new --bioc-version:

Terminal
rspm unsubscribe --repo=validated-r --source=validated
rspm subscribe --repo=validated-r --source=validated --bioc-version=3.22

Subscribing again places the source last in the repository’s source order, behind any CRAN source you subscribed before it. Source order decides which source serves a package that more than one of them offers, so re-pointing can change where such a package comes from. Use rspm reorder to put the sources back in the order you want.

Removing a version removes only the curation, meaning the list of packages that version served. The package files themselves belong to the mirrored Bioconductor source it curated from, so they stay on disk and other repositories can still serve them.

Removing the last remaining version leaves a valid empty source, equivalent to one just created with rspm create source. It does not delete the source.

WarningRe-adding a removed version needs a requirements file

A removal leaves no package set behind, so the refresh form of the command has nothing to carry forward. This sequence does not restore what 3.22 held:

Terminal
rspm update --source=validated --bioc-version=3.22 --remove --commit
rspm update --source=validated --bioc-version=3.22 --snapshot=2026-04-09 --commit   # does not restore the packages

Pass --file-in again to re-add the version.

Pairing with a CRAN Source

A curated Bioconductor source contains Bioconductor packages only, and most Bioconductor packages depend on CRAN packages. Users therefore need CRAN alongside it. How you provide it depends on which repository type serves the curated source:

  • An R repository can subscribe a CRAN source of its own, so a single repository URL covers both halves. A full CRAN mirror, a curated-cran source, and a CRAN snapshot source all work.

  • A Bioconductor repository cannot subscribe a CRAN source at all. It accepts only its Bioconductor-family source, and rspm subscribe rejects anything else:

    Output
    Error: Bioconductor repos cannot subscribe to sources.

    Provide CRAN as a separate repository instead, and have users configure both. This is the arrangement the Setup page generates for a Bioconductor repository.

Either way, what matters is that the CRAN packages the Bioconductor release expects are available at compatible versions.

For a Bioconductor repository, the Setup page can pair the separate CRAN repository into the snippet it generates, but only one kind of CRAN repository qualifies: one whose sole source is a full CRAN mirror. The page never offers a repository backed by a CRAN snapshot source or a curated-cran source, so pair one of those by editing the generated snippet by hand. That restriction is what keeps the CRAN half of a generated snapshot URL valid.

Without CRAN, the Bioconductor packages still serve, but installing any package that depends on CRAN fails, and not always visibly. See When the CRAN Pairing Is Wrong below. Nothing checks the pairing for you, and on a Bioconductor repository there is no CRAN subscription to check.

WarningThe CRAN pairing is not validated

Package Manager does not check that the CRAN source you pair with a curated Bioconductor source suits the Bioconductor release, so choosing a compatible CRAN snapshot is yours to get right. Bioconductor publishes the CRAN state each release was built against.

Pairing a recent Bioconductor release with a much older CRAN snapshot is the case to watch. A 2026 Bioconductor release paired with a 2017 curated CRAN source will resolve its Bioconductor packages and then fail to install them, because the CRAN versions they need did not exist yet. For what that looks like on a client, see When the CRAN Pairing Is Wrong.

A curated Bioconductor repository serves precompiled binaries just as a mirrored one does. Packages whose LinkingTo field names a CRAN package, such as DESeq2 and BiocParallel, additionally require that some repository on this server expose a CRAN source, which is what causes Package Manager to synchronize the CRAN package data it resolves against. Any of the pairings above satisfies that, and so does a CRAN repository elsewhere on this server that nobody installs from. Without one, the affected packages are served from source and installation still succeeds. See Binaries for Bioconductor Sources and Cross-Ecosystem Binary Dependencies.

That requirement is about this server, and it is unrelated to where the client resolves CRAN from. The two are easy to conflate, because everything else in this section is about the client’s CRAN. A client whose only CRAN repository was a public one still received a BiocParallel binary from a Bioconductor repository that had no CRAN subscription of its own, because a different repository on the same server exposed a CRAN source. When binaries are missing for these packages, look at what this server exposes, not at what your users have in repos.

When the CRAN Pairing Is Wrong

A mismatched CRAN pairing does not produce one recognizable error, and none of the shapes it does produce names the snapshot date or the mismatch. Pairing a 2026 Bioconductor release with a CRAN snapshot from several years earlier produces three:

  • A false diagnosis, and the only shape that exits non-zero: package 'BiocManager' is not available for this version of R. That is not what happened. BiocManager is fine for the R version that is running; it is absent from the CRAN date you chose.

  • A missing dependency, with remediation advice that cannot work. The install exits 0:

    Output
    Warning: dependency 'generics' is not available
ERROR: dependency 'generics' is not available for package 'BiocGenerics'
Perhaps try a variation of: install.packages('generics')
* removing '/tmp/rlib/BiocGenerics'

    Following that suggestion fails too, because the package does not exist on the CRAN snapshot at all, at any version.

  • A build failure from an era-appropriate CRAN package that no longer compiles under a current R, for example Error: unable to load R code in package 'lambda.r'. The package and the R are each fine on their own; the pairing put them together.

When a client installs from a binary URL, the missing-dependency shape changes into something harder to notice. R checks a source package’s dependencies before installing it and refuses; it does not apply that gate to a binary. The same repository, the same missing dependency, and two URLs give two outcomes:

Output
# Source URL:
ERROR: dependency 'generics' is not available for package 'BiocGenerics'
* removing '/tmp/rlib/BiocGenerics'

# Binary URL:
Warning: dependency 'generics' is not available
* installing *binary* package 'BiocGenerics' ...
* DONE (BiocGenerics)

The binary install exits 0, leaves the package on disk, and reports * DONE. The dependency is still missing, so library(BiocGenerics) then reports package 'generics' required by 'BiocGenerics' could not be found. It can go further than that: with a mismatched CRAN, BiocParallel reached * DONE, attached, and computed correct results, while futile.logger and lambda.r, both of which it declares under Imports:, were absent from the library. The only warning is the Warning: line in the install log, which scrolls past and does not affect the exit status.

This mechanism is R’s and Package Manager cannot change it. What it means for you is that a scripted install from a binary URL cannot be trusted to fail when the CRAN pairing is incomplete. Check the install log for dependency ... is not available, and confirm with library() rather than with the exit status.

Configuring Clients

Get client settings from the Setup page in Package Manager. What that page offers depends on the repository type, so the two arrangements are configured differently.

For a Bioconductor repository, the page offers a Bioconductor version selector listing only the versions your source has curated, and generates the BioC_mirror and BIOCONDUCTOR_CONFIG_FILE settings that BiocManager needs. It omits R_BIOC_VERSION so that BiocManager picks a release from config.yaml. Choosing a date freezes the generated settings to the state that version held on that date, and freezes the paired CRAN repository to the same date. The CRAN repository it pairs is one whose sole source is a full CRAN mirror; if your CRAN comes from a CRAN snapshot source or a curated-cran source, substitute it in the generated snippet by hand. Prefer what the Setup page generates over the fixed examples in the Posit Workbench section, which are written for mirrored repositories.

For an R repository, the page has no Bioconductor version selector and generates no Bioconductor-specific settings at all. The repository is already bound to one release, and that release’s packages are in the repository’s flat index, so install.packages needs only the one repository URL that the page generates, alongside a CRAN repository to satisfy CRAN dependencies. Users need neither BioC_mirror nor BIOCONDUCTOR_CONFIG_FILE, and BiocManager is not involved.

For what the BiocManager settings do, and how a user confirms they were read, see Bioconductor in the User Guide. Two things are specific to a curated source:

  • Users must not set R_BIOC_VERSION. It pins the release outright and bypasses config.yaml, which is what lets BiocManager choose a release your repository serves.
  • Curate a release for every R minor version your users run. See Bioconductor Releases and R Versions.

Bioconductor Releases and R Versions

Bioconductor pairs each release with one R version, and BiocManager chooses a release by matching that pairing against the version of R that is running.

On a Bioconductor repository, a client whose R version matches none of the releases you curate does not fall back to something workable. BiocManager chooses a release from the generated config.yaml anyway and then fails, reporting that the release it chose requires a different R version.

On an R repository, nothing performs that matching, so the same mistake is silent. The flat index carries the one release you subscribed and no R version pairing, and install.packages does not look for one, so a client on any R version installs that release’s packages. An R 4.5.3 client installed Bioconductor 3.23’s BiocParallel 1.46.0 from a repository pinned to that release, which Bioconductor pairs with R 4.6: the install succeeded, requireNamespace() returned TRUE, and there were no warnings. It also compiled from source rather than taking a binary, because a release’s binaries are built for its own R version. So the wrong R version costs build time and installs a release paired with a different R, with nothing on the client saying so.

Curate a release for every R minor version your users run. The R Version column of rspm list sources --name=<source> --details shows the R version each curated version pairs with.

Using a Curated Bioconductor Source Offline

A curated Bioconductor source resolves its packages from the mirrored Bioconductor source’s data, so in an air-gapped installation it curates from whatever the offline downloader has placed there. rspm-offline-downloader takes no source or repository argument and does not need one. This section covers only what is specific to a curated source. For the full offline workflow, see Air-Gapped Package Manager.

To size that dataset for a curated source, give rspm-offline-downloader get bioconductor a requirements file of its own. Write it by hand rather than reusing a curated source’s file. The downloader ignores bioc_version markers instead of evaluating them, so a file that pins a different version of a package per release lists that package more than once and the download fails with duplicate package(s) in requirements file. List every package once, covering the union of what all of your curated versions need, and leave the version constraints off unless you want the offline dataset restricted to those exact versions:

Terminal
rspm-offline-downloader get bioconductor \
  --rspm-version=[version] \
  --destination=/path/to/offline \
  --versions=3.22,3.23 \
  --file-in=/path/to/requirements.txt

--file-in downloads the listed packages and the Bioconductor packages they depend on, rather than the full Bioconductor mirror. --versions names the releases you curate.

get bioconductor downloads Bioconductor packages only. It does not download the CRAN packages those Bioconductor packages depend on, so fetch them separately with get cran:

Terminal
rspm-offline-downloader get cran \
  --rspm-version=[version] \
  --destination=/path/to/offline \
  --file-in=/path/to/cran-requirements.txt

Package Manager does not work out the CRAN list for you. Use a CRAN requirements file you already maintain, or omit --file-in to download all of CRAN.

If your users install with BiocManager, list BiocManager itself in that CRAN requirements file. It is a CRAN package, not a Bioconductor one, so get bioconductor never fetches it, and without it an air-gapped client cannot install BiocManager to begin with:

Output
package 'BiocManager' is not available for this version of R
Error in library(BiocManager) : there is no package called 'BiocManager'

BiocVersion is the Bioconductor package that pairs with it, and belongs in the curated Bioconductor set instead.

Then, on the air-gapped server, create the source and commit each version with rspm update as described above. That server derives its snapshot dates from the packages the download contains, so a --snapshot date validated against an online instance is not necessarily one of them. See Snapshot dates reflect the packages you downloaded.

WarningCRAN dependencies are not downloaded for you

A curated Bioconductor source contains Bioconductor packages only, and the offline downloader mirrors that split. Nothing in get bioconductor works out which CRAN packages a Bioconductor release needs. Sizing the CRAN side is yours to do, and getting it wrong shows up at install time as a missing dependency rather than as a download error.

WarningKeep the offline requirements file cumulative

A --file-in run replaces the served index with what it downloaded, so a curated version can only be updated to packages that run fetched. Dropping a package from the offline requirements file can therefore block a later curated update. Always add to that file rather than removing from it, and keep it covering every package any of your curated versions needs.

Size the destination for that combined set rather than for any single version. Adding --include-binaries multiplies it by the distributions and architectures you ask for. It does not multiply by R version the way get cran does, because Bioconductor pairs one R version with each release, so --r-versions here only narrows which releases get binaries.

Back to top