`sysreqs_install_plan` outputs partial dependency list for some platforms (with no warning)

[brookslogan]

Here, "partially-supported platforms" appears to include supported OSs with versions that aren't in pak:::supported_os_versions() and OSs with an unsupported distribution (e.g., opensuse-tumbleweed) that, due to a very particular prefix, seems to end up being treated the same way.

pkgdepends::sysreqs_install_plan(
              "sf",
              config = list(sysreqs_platform = "opensuse-42.3")
            )$packages$sysreq # includes proj sysreq --- the correct result
#> ℹ Loading metadata database
#> ✔ Loading metadata database ... done
#> 
#> [1] "gdal"    "geos"    "openssl" "proj"    "sqlite3"
pkgdepends::sysreqs_install_plan(
  "sf",
  config = list(sysreqs_platform = "opensuse-42.2")
)$packages$sysreq # excludes proj sysreq
#> [1] "gdal"    "geos"    "openssl" "sqlite3"
pkgdepends::sysreqs_install_plan(
  "sf",
  config = list(sysreqs_platform = "opensuse-tumbleweed-20240809")
)$packages$sysreq # aborts (but this doesn't seem to be what is used downstream)
#> Error in "sysreqs2_command(sysreqs_platform, \"update\")": ! Unknown OS. Don't know how to query or install system packages for
#> opensuse-tumbleweed-20240809.
pkgdepends::sysreqs_install_plan(
  "sf",
  config = list(sysreqs_platform = "x86_64-suse-linux-gnu-opensuse-tumbleweed-20240809")
)$packages$sysreq # excludes proj sysreq
#> [1] "gdal"    "geos"    "openssl" "sqlite3"

# extra setup info:
options("repos") # RSPM + CRAN; same sorts of things appear to happen also with CRAN only
#> $repos
#>                                            RSPM 
#> "https://packagemanager.rstudio.com/all/latest" 
#>                                            CRAN 
#>                     "https://cran.rstudio.com/"
pkgdepends::current_r_platform()
#> [1] "x86_64-suse-linux-gnu-opensuse-tumbleweed-20240809"
pkgdepends::sysreqs_platforms()[9,] # opensuse-* --- but not all opensuse versions are fully supported
#> # A data frame: 1 × 7
#>   name   os    distribution version update_command install_command query_command
#> * <chr>  <chr> <chr>        <chr>   <chr>          <chr>           <chr>        
#> 1 openS… linux opensuse     *       <NA>           zypper --non-i… rpm
pak:::supported_os_versions()$opensuse
#> [1] "42.3" "15.0"
pkgdepends::sysreqs_is_supported("opensuse-42.3") # "full" support
#> [1] TRUE
pkgdepends::sysreqs_is_supported("opensuse-42.2") # but actually has "partial" support
#> [1] TRUE
pkgdepends::sysreqs_is_supported("opensuse-tumbleweed-20240809") # unsupported, but this isn't what `pak` tries
#> [1] FALSE
pkgdepends::sysreqs_is_supported("x86_64-suse-linux-gnu-opensuse-tumbleweed-20240809") # but actually has "partial" support
#> [1] TRUE

^{Created on 2024-08-13 with reprex v2.1.1}

[See also this comment for what looks like another downstream example involving redhat & units. I think this comment and my example above form a separate issue from pak#610 itself.]

Context

I was trying pak::pkg_install("sf") on OpenSUSE Tumbleweed, which fails with suboptimal feedback. (This could be improved downstream in pak by displaying or pointing to .Last.error$parent${stdout,stderr} rather than just .Last.error; in this case, stdout shows that there's an issue with using PROJ. But it seems that there's still something going amiss in pkgdepends underneath this.)

I'm not sure whether this is an instance of #320. I got the impression that it wasn't since it appeared to happen with both CRAN and CRAN+RSPM as repos, as well as both before and after successfully installing sf (with PROJ and other sysreqs).

Desired behavior

sysreqs_install_plan, when the platform isn't fully supported, will do one of the following:

• Explanatory hard error, potentially pointing to a hack like Sys.setenv("PKG_SYSREQS_PLATFORM" = "opensuse-42.3")
• Explanatory warning + current result
• Explanatory warning + use something like hack above, trying to grab dependency info from a fully-supported version

Hopefully, any of these would at least attach some additional useful context when things go wrong downstream, like in pak::pkg_install("sf") [though I haven't confirmed warnings/errors wouldn't somehow be swallowed and hidden away by pak].