Package ‘r-SASxport-1.7.0’ marked as broken

[teto]

Steps To Reproduce

rPackages.SASxport has been marked as broken, I wonder how. It seems like this was automated.

$ nix-build -A rPackages.SASxport

Build log

error: Package ‘r-SASxport-1.7.0’ in /nix/store/ycqap4jszggfbq3qyk4y7386srq4cpqi-source/pkgs/development/r-modules/generic-builder.nix:53 is marked as broken, refusing to evaluate.

       a) To temporarily allow broken packages, you can use an environment variable
          for a single invocation of the nix tools.

            $ export NIXPKGS_ALLOW_BROKEN=1

Additional context

Add any other context about the problem here.

Notify maintainers

@jbedo since the package was marked broken in 6675a16146bb25c5728d340fa40e989fe24eedb9 . I wonder how the "broken" boolean was set (automatically/manually ?).

Metadata

Using current nixos-unstable, this fork actually https://github.com/teto/nixpkgs/tree/rmarkdown-add-pandoc since I was hoping to add pandoc as an rmarkdown dependency.

[jbedo]

This was marked broken automatically. The CRAN and BioC repositories are curated in the sense that packages failing their internal checks are removed. Rather than removing the package from our tree when it is removed upstream, we mark it as broken. This is because typically these packages reappear upstream later on once a new release is made that satisfying the required criteria, and we can then just remove the broken flag (automatically) when this happens.

[teto]

thanks for the details, I've checked out the CRAN website and understand what you mean (I could find SASxport in the archives folder).

The CRAN and BioC repositories are curated in the sense that packages failing their internal checks are removed

I dont really use R, just help some colleagues getting R packages via nix. Is there a way to run these internal checks in nixpkgs ? Does CRAN keep logs about why the package got removed ? If I remove the broken = true from rPackages.SASxport and it builds fine so I wonder if I could run these checks myself to see if it's fine or how I can help.

[jbedo]

The tests CRAN use are quite extensive and are subject to change, I don't think we should try and reimplement them. We can't really maintain things that are deprecated upstream anyway, so I think it's reasonable to mark them as broken when they are no-longer available in the latest CRAN release (which rPackages reflects) and leave it to users to decide if they want to allow broken and try their luck with the latest availble archived version.