linux-aarch64 build for ncbi blast

[rpetit3]

This will likely be a work in progress as I'm guessing it will not be as simple as adding the extra line

Please feel free to make changes or suggestions

---

Please read the guidelines for Bioconda recipes before opening a pull request (PR).

General instructions

• If this PR adds or updates a recipe, use "Add" or "Update" appropriately as the first word in its title.
• New recipes not directly relevant to the biological sciences need to be submitted to the conda-forge channel instead of Bioconda.
• PRs require reviews prior to being merged. Once your PR is passing tests and ready to be merged, please issue the @BiocondaBot please add label command.
• Please post questions on Gitter or ping @bioconda/core in a comment.

Instructions for avoiding API, ABI, and CLI breakage issues

Conda is able to record and lock (a.k.a. pin) dependency versions used at build time of other recipes.
This way, one can avoid that expectations of a downstream recipe with regards to API, ABI, or CLI are violated by later changes in the recipe.
If not already present in the meta.yaml, make sure to specify run_exports (see here for the rationale and comprehensive explanation).
Add a run_exports section like this:

build:
  run_exports:
    - ...

with ... being one of:

Case	run_exports statement
semantic versioning	{{ pin_subpackage("myrecipe", max_pin="x") }}
semantic versioning (0.x.x)	{{ pin_subpackage("myrecipe", max_pin="x.x") }}
known breakage in minor versions	{{ pin_subpackage("myrecipe", max_pin="x.x") }} (in such a case, please add a note that shortly mentions your evidence for that)
known breakage in patch versions	{{ pin_subpackage("myrecipe", max_pin="x.x.x") }} (in such a case, please add a note that shortly mentions your evidence for that)
calendar versioning	{{ pin_subpackage("myrecipe", max_pin=None) }}

while replacing "myrecipe" with either name if a name|lower variable is defined in your recipe or with the lowercase name of the package in quotes.

Bot commands for PR management

Please use the following BiocondaBot commands:

Everyone has access to the following BiocondaBot commands, which can be given in a comment:

@BiocondaBot please update	Merge the master branch into a PR.
@BiocondaBot please add label	Add the please review & merge label.
@BiocondaBot please fetch artifacts	Post links to CI-built packages/containers. You can use this to test packages locally.

Note that the @BiocondaBot please merge command is now depreciated. Please just squash and merge instead.

Also, the bot watches for comments from non-members that include @bioconda/<team> and will automatically re-post them to notify the addressed <team>.

[rpetit3]

missing depends

conda_build.exceptions.DependencyNeedsBuildingError: \
Unsatisfiable dependencies for platform linux-aarch64: \
  {
    MatchSpec("ncbi-vdb"),
    MatchSpec("entrez-direct==11.0=pl526_1"),
    MatchSpec("perl-html-parser")
  }

ncbi-vdb
entrez-direct
perl-html-parser

[rpetit3]

@cbrueffer how difficult is it to move Perl packages to conda-forge?

I've identified two, perl-html-parser and perl-xml-libxml, that I think I might move over to conda-forge

[bgruening]

The work from @jvolkening might help as well conda-forge/staged-recipes#25110

[jvolkening]

@cbrueffer how difficult is it to move Perl packages to conda-forge?

I've identified two, perl-html-parser and perl-xml-libxml, that I think I might move over to conda-forge

@rpetit3 I've been working on a mass migration of Perl recipes to conda-forge. Right now the biggest hold-up is just waiting on eyeballs to review the PRs, understandably. The issue that @bgruening referenced contains some notes on the process, but it's a pretty long read at this point. A few of the main points I've learned so far:

1. Perl packages can't truly be noarch right now because the conda-forge *nix and Windows Perl builds use a different directory structure for the library files. I have an open PR with a native Windows Perl build and unified directory structure, but again just waiting on eyeballs for review.

2. A significant fraction of existing Perl package recipes include dependencies that have been part of core Perl for a decade or more and thus don't need to be explicit requirements. I've been cleaning these up as part of the migration, and I think it's a good time to do this if you're migrating those recipes.

[peterjc]

It looks like the more recent #49443 (merged) also tried to do macOS and Linux ARM, but gave up due to Perl dependencies and settled on just fixing the blast packages on Intel macOS. It looks like quite a few perl dependencies not yet available on ARM...

I tried working on perl-io-compress in #49947 which immediately hit three perl packages in conda-forge, all currently stuck. e.g. conda-forge/perl-scalar-list-utils-feedstock#4 which I think is down to clang warnings being treated as errors.