# Bioconductor Installation Errors: Causes and Fixes The single most common cause of bioconductor installation errors is a version mismatch between your R installation and the Bioconductor release you are trying to install from. The first thing to check takes about thirty seconds. Open R and run these two commands. ```r R.version.string BiocManager::version() ``` If the R version printed by the first command is older than the minimum R version required by your Bioconductor release, nearly every install attempt will fail or produce a cascade of warnings that look like unrelated bugs. As a concrete example, the tidyCoverage package states it is available from Bioconductor 3.19 and requires R 4.4 or later, and that pairing is typical of how each Bioconductor release is locked to a specific R version [1]. If you see a warning during install telling you that your R version is too old or that a package requires a newer R version, fix that first. Most other problems are cheaper to solve and will stay solved once the version foundation is correct. This guide explains how Bioconductor installation actually works, walks through the causes of failed installs from the most common to the rarest, gives you a table you can scan when an error message appears mid-install, and finishes with a diagnostic sequence and prevention habits that keep an R for bioinformatics environment stable over months of real work. ## How Bioconductor Installation Works Under the Hood ![Six step flow showing how BiocManager picks a release, resolves dependencies, downloads, compiles, links system libraries and writes packages.](/article-images/illustrations/bioconductor-installation-errors-install-mechanism.webp) Understanding the mechanism makes every error message easier to read. Bioconductor is not a single download. It is a distributed collection of roughly two thousand R packages hosted in dedicated repositories, installed through a coordinator package called `BiocManager` rather than through ordinary CRAN installs. When you call `BiocManager::install("SomePackage")`, the following happens in sequence. 1. BiocManager determines which Bioconductor release matches your R version. 2. It resolves the package you asked for and every package it depends on, transitively. 3. It downloads each dependency from the correct repository, CRAN for some, Bioconductor for others. 4. For packages distributed as source, it invokes your C and C++ compiler toolchain to build them. 5. It links compiled code against system libraries such as libxml2, libcurl, and HDF5. 6. It writes the finished packages into a library directory on your filesystem. Failure can occur at any of those six steps, and the error message you see is almost never the root cause. Because Bioconductor packages are layered on top of each other, a failure deep in the dependency chain surfaces as an error about the package you actually wanted. The infrastructure paper for the InteractionSet package describes this pattern explicitly. InteractionSet provides data classes for Hi-C and ChIA-PET experiments by exploiting existing Bioconductor infrastructure, and it is in turn used by higher-level packages, a design that improves interoperability but stacks dependencies many layers deep [2]. Install the top of that stack and the installer must succeed at every layer below it. Two consequences follow from this design and explain most bioconductor installation errors causes. First, dependency resolution is aggressive by design. The exvar package, a wrapper for [gene expression](/blog/guides/gene-expression) analysis and variant calling, is built on multiple CRAN and Bioconductor packages [3], and the tidyomics ecosystem similarly bridges Bioconductor objects to tidy R paradigms across six data frameworks and ten analysis tools [4]. Installing a single modern package can therefore pull in one to two hundred dependencies. Any one of them failing aborts the whole chain, which is why your terminal can scroll through hundreds of successful downloads and still end in failure. Second, many core packages contain compiled code. The beachmat package exists specifically because single-cell RNA-seq experiments produce matrices too large for dense in-memory R representations, so it provides a C++ API that reads efficiently from dense, sparse, and file-backed matrix types [5]. Compiled packages need a working compiler and the correct system headers on your machine. A missing operating system library produces error text about C++ headers and exit statuses that looks nothing like a missing-library problem, which is why readers of any bioconductor tutorial routinely misdiagnose it. ## Troubleshooting Table: Symptoms, Causes, and Fixes Scan this table for the last distinctive message in your install log, then apply the fix column. The detailed sections after the table explain the mechanism behind each row. | Symptom in the console | Likely cause | How to confirm | Fix | |, - |, - |, - |, - | | `there is no package called 'BiocManager'` | BiocManager itself is not installed | Run `install.packages("BiocManager")` | Install it from CRAN, then use `BiocManager::install()` for all Bioconductor packages | | `Error in loadNamespace` or `package or namespace load failed` for a dependency during install | A dependency failed to install or load, aborting the chain | Scroll up to the first `ERROR` or first `non-zero exit status` | Install the failing dependency by name directly, then retry the original package | | `Warning message: package 'X' is not available (for R version ...)` | R version too old, or you used `install.packages()` for a Bioconductor-only package | Run `BiocManager::version()` and compare with the package's landing page | Update R, or install through `BiocManager::install("X")` | | `fatal error: xml2/xml.h: No such file or directory` (or curl, ssl, png, hdf5 headers) | Missing system development library | Search the log for the first `fatal error` | Install the matching system library with dev headers, then reinstall the package | | `ERROR: dependencies 'X', 'Y' are not available` | Earlier dependencies failed silently or were skipped | Run `BiocManager::install(c("X","Y"))` | Install the named dependencies explicitly, then retry | | `installation of package had non-zero exit status` | Generic failure marker, root cause is earlier in the log | This line is the last line. The cause is above it | Never debug this line. Find the first error above it | | `Warning: unable to access index for repository` or repeated download timeouts | Mirror, proxy, or network problem | Try a different CRAN or Bioconductor mirror | Switch mirrors with `options(repos = ...)` or check institutional proxy settings | | `package 'X' is in use and will not be updated` | The package is loaded in your current session | Run `sessionInfo()` and check loaded namespaces | Restart R with a clean session, then install | | `Warning in install.packages : installation of package had non-zero exit status` only for vignette-building packages | Missing LaTeX or rendering tools for vignettes | Error mentions `pdflatex`, `texlive`, or a vignette file | Install a TeX distribution, or install with `dependencies = TRUE` and skip vignette builds | | Package installs with a warning that it was `built under R version ...` and fails on load | Stale binary built for a different R version | Compare the binary's R version with yours | Update R, or force a source install with `BiocManager::install("X", type = "source")` | | `ERROR: dependency 'X' is not available for package 'Y'` where X exists on GitHub but not Bioconductor | Version mismatch between release and development branches | Check the package landing page for its Bioconductor release | Match your Bioconductor version to the package's stated release | | Install hangs at the same percentage repeatedly | Disk full or memory exhausted during compilation | Check free disk space and system memory with your OS monitor | Free space or add swap, then retry | | `cannot remove prior installation of package` | Package files locked by a running R process or permissions issue | Check for other R sessions and library write access | Close other R sessions, restart, and reinstall | ## Bioconductor Installation Errors Causes, From Most Common to Rarest ### Version Mismatch Between R and Bioconductor Each Bioconductor release pairs with a specific R version, and the project enforces this pairing at install time. Bioconductor issues two coordinated releases per year, and each release deprecates packages that no longer meet its standards while upgrading requirements for the rest. When your R version falls behind, three distinct failure modes appear. The first is an explicit refusal. BiocManager prints a warning that your R version does not meet the requirement for the release you are targeting and may stop or proceed into a broken state. The second is a warning that a specific package `Depends on R version >= X`, which means the package author declared a minimum R version in the package metadata. The third and most confusing is silent breakage where packages install but fail on load with errors about missing functions in base packages, because the package was built against a newer R API. The tidyCoverage package gives a concrete anchor for what these requirements look like in practice. Its documentation states availability from Bioconductor 3.19 with R 4.4 or later [1]. When you see such a statement on a package page and your machine runs an older R, the package is simply not reachable from your current release, and no amount of retrying changes that. How to fix bioconductor installation errors of this type: upgrade R itself. R releases come from the Comprehensive R Archive Network, and the upgrade is a normal operating system install that does not disturb your package library, although packages generally need reinstalling after a major R upgrade. After upgrading R, reinstall BiocManager if needed, run `BiocManager::install()` with no arguments once to align all installed packages with the new release, and answer yes when it offers to update packages. A related trap is mixing releases. If you previously installed packages from the development branch and then switch to the release branch, or the reverse, versions collide. BiocManager warns about this and suggests an update. Accept the update, and prefer `BiocManager::valid()` afterward to verify that every installed package is consistent with your release. ### Using install.packages() Instead of BiocManager This cause is common among readers new to R for bioinformatics because CRAN habits carry over. `install.packages()` searches CRAN repositories by default. A Bioconductor package such as TFBSTools, which is distributed from the Bioconductor website under a GPL license for [transcription factor binding site analysis](/knowledge/molecular-biology/transcription-factor-binding-site-analysis-how-to-interpret-chip-seq-and-motif-data-to-predict-gene) [6], or CAGEr, which the authors state is freely available from Bioconductor for cap analysis of gene expression data [7], may not exist on CRAN at all. The installer then reports `package 'X' is not available`, which reads like the package does not exist when it actually lives in a different repository. The confirmation is simple. Search the package name at the Bioconductor website. If it appears there with a vignette and a landing page, install it with `BiocManager::install("X")`. BiocManager resolves both repositories correctly and pins the versions that match your release, which plain `install.packages()` cannot do reliably. Since BiocManager replaced the older BiocInstaller mechanism years ago, any older script or forum answer suggesting `source()` of an installer script is obsolete and should be replaced with the BiocManager approach. ### Missing System Libraries and Compiler Toolchains This is the largest single category of compilation failures on macOS and Linux. Bioconductor packages that do real computation frequently contain C, C++, or Fortran code. The beachmat package described earlier is a C++ API for high-throughput biological data access [5], and MSnbase version 2 introduced on-disk infrastructure for handling large raw mass spectrometry experiments on commodity hardware, again requiring compiled components [8]. When R builds these packages from source, the compiler needs header files from system libraries. Development libraries are separate packages from the runtime libraries your operating system already has, so a machine that runs fine can still lack the headers. The error signature is a line inside a long compile log that looks like `fatal error: someLib/someHeader.h: No such file or directory`, followed by compilation termination and finally the misleading `non-zero exit status`. The fix is to install the matching development library through your system package manager, then reinstall the R package. On Ubuntu and Debian, development packages conventionally end in `-dev`. On Fedora and Red Hat systems they end in `-devel`. On macOS, Homebrew supplies them, and the Apple Xcode command line tools supply the compiler itself. On Windows, the Rtools bundle supplies the toolchain, and its version must match your R major version. Frequently needed libraries for bioinformatics packages include libxml2, libcurl, OpenSSL, libpng and libjpeg for imaging, poppler for PDF processing, HDF5 and NetCDF for high-dimensional data, the GSL scientific library, and ImageMagick for figure handling. A pragmatic approach when you hit repeated header errors is to install the common set for your platform in one step, because a single analysis pipeline often touches most of them. The exvar package, for instance, chains together expression analysis and variant calling [3], which pulls in imaging, XML, and networking dependencies in one install. A safety note applies here. Commands that install system libraries require administrator privileges, and copied one-line install commands from forums can execute far more than they appear to. Read each command before running it with elevated privileges, and prefer your operating system's official package repositories or the commands published in the package's own README over third-party instructions. ### Deep Dependency Chains Bioconductor packages are deliberately layered. The GenomicInteractions package for chromatin interaction data [9] and the InteractionSet infrastructure beneath it [2] illustrate the pattern in one domain. Higher-level packages provide analysis and visualization by building on lower-level data containers, and those containers themselves build on core classes such as SummarizedExperiment. The tidyCoverage package extends SummarizedExperiment directly for genomic coverage data [1], and the QTLExperiment and multistateQTL packages describe themselves as building on existing Bioconductor infrastructure and conventions for storing QTL summary statistics [10]. The practical consequence is that a single `BiocManager::install("SomeAnalysisPackage")` can trigger installation of one hundred or more dependencies. Three failure patterns emerge from this scale. Timing failures occur when a dependency updates mid-chain and the chain mixes versions. The fix is to run the install again, since the second pass resolves to consistent versions. Skip failures occur when a dependency fails and the installer continues with other packages, then reports at the end that several dependencies are unavailable. The terminal summary names them. Install each one individually so you can see its specific error, fix it, and return to the original package. Version ceilings occur when one dependency requires a newer Bioconductor release than the package you wanted, which circles back to the version mismatch cause above. One habit prevents most chain failures. Before installing a major package, run `BiocManager::install()` alone and let it update everything already installed. Updating first means the new package installs against a coherent, current library rather than against a mixture of versions accumulated over months. ### Package Not Available in Your Release or Under Maintenance Bioconductor removes or retires packages between releases when they fail builds, violate policies, or are superseded. A package you saw in a paper or tutorial last year may be absent from the current release. There is also a delay window when a brand new package exists in the development branch but has not yet propagated to the release branch, so users on release see `not available` while the package page shows it under devel. Confirmation requires checking two things on the package landing page. Check which release versions the package appears in, and check the date of the latest build. If the package exists only under devel, your options are to wait for the next release, to switch your whole library to the devel branch with `BiocManager::install(version = "devel")`, or to install from the maintainer's GitHub repository. Switching branches is a heavyweight decision because it moves every package, not just one, and development branches expect a matching development R version. SBGNview, a comprehensive package for pathway analysis and visualization across over 5200 reference pathways and more than 3000 species, is available on both GitHub and Bioconductor [11]. That dual distribution is common for active packages and provides the fallback path when release timing is the problem, but it introduces its own risks covered in a later section. ### Library Path and Permission Problems R installs packages into a library path, and the first writable path in `.libPaths()` receives the install. Two problems are frequent on shared systems such as university servers. When the default library is a system directory you cannot write to, the installer either fails with permission errors or, more helpfully, offers to create a personal library. Accepting the personal library offer is usually correct. The failure mode people stumble on is having created a personal library for one R version and then upgrading R, since personal libraries are version-specific by convention. After an R upgrade, the new session cannot see the old library, which looks like all your packages vanished. They did not. They sit in the previous version's library directory. A second pattern occurs when packages were originally installed with administrator privileges and are now owned by root. Later updates from your normal user account fail with permission errors. The durable fix is to reinstall affected packages into a user-owned library rather than to keep fixing ownership, and to configure the `R_LIBS_USER` environment variable so the personal library is consistent across sessions. Confirm the current situation with `.libPaths()` and `file.exists()` on each path. If you did not intentionally install with elevated privileges and see paths you cannot write to, that mismatch is the cause. ### Memory, Disk, and Compiled Code Constraints Bioinformatics packages carry large data payloads. Annotation packages bundle full genome annotations, and experimental data packages ship example datasets, so a Bioconductor library grows quickly. Installations fail at the very end with disk-full errors, or compilation of a large package is killed by the operating system because the compiler ran out of memory, which appears as a killed process rather than an ordinary error message. Confirm by checking free disk space on the partition holding your R library and watching memory during a compile. The fix is mundane. Free space, move the library to a larger partition, or on memory-constrained machines limit parallel compilation so fewer compiler processes run at once, which BiocManager supports through its `Ncpus` argument. Runtime memory is a separate but related problem that package authors have addressed architecturally. MSnbase's on-disk infrastructure lets large raw mass spectrometry experiments be processed on commodity hardware without loading everything into memory [8], and beachmat's file-backed matrix support trades some access speed for large-scale storage efficiency [5]. Knowing that these patterns exist matters for installation in one way. File-backed workflows require backing packages such as HDF5 support, so when a package recommends on-disk mode, verify that the corresponding system library was installed, otherwise you trade an install-time error for a first-use error. ### Network, Mirror, and Proxy Failures Download failures produce timeouts, `cannot open URL` messages, or SSL certificate errors. Institutional networks with proxies are the classic setting, but the causes range from a temporarily unhealthy mirror to a corporate firewall blocking the Bioconductor server. Diagnose by elimination. Retry once, since mirrors have transient bad moments. Then switch mirror explicitly with `options(repos = BiocManager::repositories())` after choosing a different geographic mirror, or set the mirror directly in your options. If only HTTPS downloads fail, your system's certificate store or your network's SSL interception is the likely cause, and your institution's IT support resolves it. Persistent proxy environments need the `http_proxy` and `https_proxy` environment variables set before R starts. One specific and misleading case is a partial download. A package tarball cut off mid-transfer can produce checksum or unexpected-end-of-file errors. Clearing the temporary download directory, or simply restarting R so a new temporary directory is used, resolves it. ### GitHub, Source, and Mixed-Repository Conflicts Installing a package from GitHub when a Bioconductor version also exists creates a shadow that BiocManager will flag on every future validity check. The GitHub copy may be a development snapshot ahead of, or behind, your release. When other packages depend on the Bioconductor version, your library now contains two different versions of the same package, and load order decides which one wins, producing errors that change between sessions. The tidyomics ecosystem illustrates why this matters. It bridges Bioconductor infrastructure to tidy R programming across many frameworks [4], so a stale GitHub shadow of a core package can break packages across the whole ecosystem, not just the one you installed from GitHub. The fix is to prefer the Bioconductor version whenever one exists, and to remove the GitHub copy explicitly before installing the release version. Reserve GitHub installs for packages not yet on Bioconductor or for a specific bug fix a maintainer published there. Record which packages you installed that way, because six months later they are the first suspects when a shared workflow breaks. ### External Tool Dependencies Some Bioconductor packages wrap external command-line software and require it to be present on your system. The rTANDEM package interfaces the X!Tandem protein identification algorithm and can run its multi-threaded engine directly from R as part of an MS/MS proteomic pipeline [12]. If the external executable is missing, the package may install cleanly and fail at first use, or its configuration step may fail during install with an error about a binary not found. Read the package README before installing packages in this category. Install the external tool through your system package manager or the vendor's documented route, confirm the executable is on your PATH, then install the R package. Packages built on Java or on specific external databases follow the same pattern. ## A Diagnostic Sequence You Can Follow ![Decision path that sends a reader from the first error line to a version check, a repository check, a system library fix or a dependency install.](/article-images/illustrations/bioconductor-installation-errors-first-error-triage.webp) When an install fails and the table above does not immediately resolve it, work through this sequence in order. Each step either fixes a common cause or narrows the search space. 1. Restart R completely. On RStudio, use Session, then Restart R. Loaded packages and stale temporary state cause a real fraction of failures. 2. Read the first error, not the last. Scroll to the first line containing `ERROR`, `fatal error`, or `non-zero exit status`. Everything after it is fallout. 3. Confirm your versions with `R.version.string` and `BiocManager::version()`. Fix version mismatches before anything else. 4. Confirm the repository. If the package appears on the Bioconductor website, use `BiocManager::install("X")`, never plain `install.packages("X")`. 5. Update your existing library. Run `BiocManager::install()` with no arguments and accept updates, then retry the original install. 6. If compilation failed, identify the header or tool named in the first fatal error, install the matching system development library, and retry. 7. If a named dependency is unavailable, install it alone and read its own error. Fix dependencies bottom-up, one explicit install at a time. 8. Check disk space and memory if compiles are killed or downloads stall. 9. Check for a loaded-package conflict with `sessionInfo()` if updates are refused, and restart clean. 10. Run `BiocManager::valid()` at the end. It reports any packages still inconsistent with your release, which becomes your to-do list. Most failures die at step 2 or 6. The sequence is ordered so that the cheap, high-yield checks come first and the expensive, environment-level checks come last. ## Prevention Practices Once your environment is healthy, these habits keep it healthy, and they are the difference between a machine where installs are routine and one where every install is an investigation. Update on a schedule, not at the moment of desperation. Run `BiocManager::install()` with no arguments at a time when you can afford an hour, ideally soon after each April and October Bioconductor release, so your library never drifts far from the release it belongs to. After updating, run `BiocManager::valid()` and address what it reports while the changes are fresh. Update R promptly when a new Bioconductor release raises the minimum version. The pairing between releases and R versions is fixed, so an aging R guarantees aging options. Match your toolchain to your R version on Windows by keeping Rtools current, and keep the Xcode command line tools updated on macOS. An outdated toolchain fails after every R upgrade and is easy to forget because it is invisible until needed. Install the common system development libraries for your platform once, early, when you set up a machine for R for bioinformatics work. Doing it proactively removes the most frequent interruption class entirely. Keep analysis projects reproducible with a project-local library manager or container image that records package versions. Reproducible workflows are a stated goal of the Bioconductor project, and published package papers consistently pair their software with example workflows and vignettes designed to be run end to end [13]. Vignettes are also the best functional test of an install. If a package's vignette code runs, your install is genuinely working, not merely present. ShortRead, the long-standing package for input and quality assessment of high-throughput sequencing data, ships its workflows precisely this way, with a vignette outlining typical workflows [13]. Distribute installs over parallel workers with the `Ncpus` argument when installing many packages, which shortens the window during which versions could shift and makes dependency-heavy installs far less tedious. Prefer the Bioconductor copy of every package unless you have a specific reason for a GitHub or source install, and write down the exceptions. ## Common Mistakes and Limitations These are the errors in judgment that turn a ten-minute fix into an afternoon. Debugging the last line of the log. `non-zero exit status` is a verdict, not a diagnosis. The root cause is always higher up, usually the first fatal error. Readers who grep the last line waste more time than any other single mistake. Fixing symptoms out of order. Installing a missing library while your R version is two years old just moves the failure. Confirm versions first, every time. Mixing package managers. Installing some packages with `install.packages()`, some with BiocManager, and one from GitHub produces a library that no single tool can validate. Pick BiocManager as the default for Bioconductor packages and document exceptions. Blind force-reinstalls. Repeatedly reinstalling the package that errored, when the error was in a dependency, burns time without changing the outcome. Install the dependency by name so you can see its specific failure. Ignoring warnings during install. Bioconductor installation errors often announce themselves as warnings several steps before the hard failure. A warning about a package built under a different R version, or a dependency skipped, is the failure in slow motion. Assuming the newest is safest. The development branch has the newest packages and the least testing. For real analyses, use the release branch and accept the occasional delay for a brand-new package. Treating a vignette-less install as complete. If vignette building failed because a TeX distribution is missing, the package still installed, and that is acceptable if you do not need the vignette. But be aware which packages installed without their documentation, because a bioconductor tutorial you follow later may assume the vignette is present locally. One limitation belongs in the open. Individual environments vary enormously, with different operating systems, library paths, toolchains, and network conditions, so no fixed sequence covers every case. When your specific environment resists diagnosis, the package's own Bioconductor landing page, its vignette, and its support forum are the appropriate next resources, and posting there with your full session information gets faster answers than any generic checklist. ## Frequently Asked Questions ### Do I need to reinstall R to fix bioconductor installation errors? Only when a version mismatch is the cause. If `BiocManager::version()` reports that your R version is below the minimum for your target Bioconductor release, upgrading R is the correct fix. Most other errors, including missing libraries, network failures, and dependency chains, are fixable inside your existing R installation. ### Why does install.packages() fail for packages that clearly exist on Bioconductor? Because `install.packages()` searches CRAN by default, and Bioconductor packages live in separate repositories. Use `BiocManager::install("PackageName")`, which resolves both CRAN and Bioconductor and selects versions matched to your release. ### How do I check which Bioconductor version I am using? Run `BiocManager::version()` inside R. Pair it with `R.version.string` so you can compare your R version against the minimum requirement stated on the release page or on the package's landing page. ### Why do so many packages install at once when I only asked for one? Bioconductor packages are layered, and the installer resolves every transitive dependency before installing the package you named. A single modern analysis package can pull in over a hundred dependencies, and any one failing aborts the chain. ### Can I install Bioconductor packages without compiling C or C++ code? On Windows and macOS, official binary packages let you skip compilation for most release-branch packages. Packages only available as source, or packages you install from the development branch, require a working compiler toolchain and the matching system libraries. ### Should I install the release or the development version of Bioconductor? Use the release for real analyses. Choose the development branch only when you need a package or fix that has not yet reached release, and understand that it moves your entire library, not just one package, and pairs with a development R version. ### How do I fix an installation that worked yesterday and broke after an update? Restart R, run `BiocManager::install()` with no arguments to bring the whole library to a consistent state, then run `BiocManager::valid()` to find anything still inconsistent. If a single package broke, reinstall it by name after the full update so it builds against the updated dependencies. ### How much disk space do Bioconductor packages need? There is no single fixed figure, because annotation and data packages vary widely in size and a full analysis library accumulates many of them. Plan for a growing multi-gigabyte library, check free space before large installs, and watch for install failures at the final write step, which usually indicate the disk filled during installation. ## Sources 1. [Epigenomics coverage data extraction and aggregation in R with tidyCoverage.](https://pubmed.ncbi.nlm.nih.gov/39073878/) 2. [Infrastructure for genomic interactions: Bioconductor classes for Hi-C, ChIA-PET and related experiments.](https://pubmed.ncbi.nlm.nih.gov/27303634/) 3. [Efficient and easy gene expression and genetic variation data analysis and visualization using exvar.](https://pubmed.ncbi.nlm.nih.gov/40210898/) 4. [The tidyomics ecosystem: enhancing omic data analyses.](https://pubmed.ncbi.nlm.nih.gov/38877315/) 5. [beachmat: A Bioconductor C++ API for accessing high-throughput biological data from a variety of R matrix types.](https://pubmed.ncbi.nlm.nih.gov/29723188/) 6. [TFBSTools: an R/bioconductor package for transcription factor binding site analysis.](https://pubmed.ncbi.nlm.nih.gov/26794315/) 7. [CAGEr: precise TSS data retrieval and high-resolution promoterome mining for integrative analyses.](https://pubmed.ncbi.nlm.nih.gov/25653163/) 8. [MSnbase, Efficient and Elegant R-Based Processing and Visualization of Raw Mass Spectrometry Data.](https://pubmed.ncbi.nlm.nih.gov/32902283/) 9. [GenomicInteractions: An R/Bioconductor package for manipulating and investigating chromatin interaction data.](https://pubmed.ncbi.nlm.nih.gov/26576536/) 10. [Orchestrating multi-state QTL analysis with Bioconductor.](https://pubmed.ncbi.nlm.nih.gov/42231150/) 11. [SBGNview: towards data analysis, integration and visualization on all pathways.](https://pubmed.ncbi.nlm.nih.gov/34864890/) 12. [rTANDEM, an R/Bioconductor package for MS/MS protein identification.](https://pubmed.ncbi.nlm.nih.gov/24700319/) 13. [ShortRead: a bioconductor package for input, quality assessment and exploration of high-throughput sequence data.](https://pubmed.ncbi.nlm.nih.gov/19654119/)