Initial notes

[greenc-FNAL]

1. In what way(s) could the desired functionality be provided by (or leverage, or learn from) spack external (find|list|read-cray-manifest)?
2. I would prefer to reduce the presence of hard-wired data (flag_not_buildable, base_packages, version discovery via runversion()) in this command implementation as much as reasonably possible, whether by discovery, user input or (user-configurable) specification of external files.
3. I would prefer to execute alteration of packages config via internal Spack functions, and the addition of the ability to specify global or environment scope per invocation.

[marcmengel]

1. spack external find is based largely on recipes implementing executables=, determine_version(), and determine_variants(), which a paltry 135 of the 3645 packages in builtin currently implement, and pretty much none of our packages currently have such. The closest I could get to unifying them would be to put a hook that makes the default executables list the package name / library name listing and a default determine_version() that checks rpm/apt/etc. and falls back to the current runversion logic... not sure what we do about the name-mapping. You could similarly default the determine_variants to one that looks for variant strings in the command-name --version output; but that would possibly give false positives(?)

2. -- I am unclear on a single rule for whether things should be buildable; we have several reasons for making things not buildable, we set it for things which are:

• part of our preference for system glibc virtual implementation on linux (iconv, rpc, etc.)
• part of trying to not rebuild X11 generally (most of them)
• something we are convinced is really version independent and used as commands: (diffutils, tar, etc. )
• security related and we prefer system versions (openssl) so system updates will keep us secure
  We could make separate lists for those cases and make option flags or something?

Similarly, the list of names of what to check for/ spack-package-to-rpm-name-mapping list is somewhat arbitrary.
Basing it off of the system itself means you cannot say "you really should install RPM lib-whatever" because then you're
unaware of things not on the system...

3. is done... you can give the --scope for the file on the command line.

[greenc-FNAL]

My main worry motivating point (2) is that the reasoning for any given attribute here is very subjective, and not really compatible with the idea of this functionality as a generally-available Spack command without a whole bunch of caveats, notes, and user customizability.

[marcmengel]

I think this particular package is a good candidate for calling fermi-specific. I mean, we can give options to override / configure the packages list and the not buildable list. but certainly the defaults would be our Fermi specific ones...

[marcmengel]

Adding in here, it may make sense to get rid of command-line rpm and apt calls here, and use the dnf / apt python bindings:
https://dnf.readthedocs.io/en/latest/api_queries.html#dnf.query.Query
https://apt-team.pages.debian.net/python-apt/library/apt_pkg.html

[greenc-FNAL]

Is everything we want to do doable in dnf/apt? dnf replaces yum, not specifically rpm, right?

[marcmengel]

Both of them have a way to examine what is currently installed on the system, so that's the toolchain to use. They also know whats available to be installed, so we could make more intelligent recommendations of system pacakges to install -- currently we have some packages in our list that are SL7-only and some that are AL9-only, and we recommend their installation incorrectly...