Ricardo Wurmus writes:
> Roel Janssen <r...@gnu.org> writes:
>> Ricardo Wurmus writes:
>>> Roel Janssen <r...@gnu.org> writes:
>>>> * gnu/packages/bioinformatics.scm (r-rbgl): New variable.
>>>> gnu/packages/bioinformatics.scm | 24 ++++++++++++++++++++++++
>>>> 1 file changed, 24 insertions(+)
>>>> diff --git a/gnu/packages/bioinformatics.scm
>>>> index ffb9692..3d607cc 100644
>>>> --- a/gnu/packages/bioinformatics.scm
>>>> +++ b/gnu/packages/bioinformatics.scm
>>>> @@ -5309,6 +5309,30 @@ packages.")
>>>> CRAN, and (some) github packages.")
>>>> (license license:artistic2.0)))
>>>> +(define-public r-rbgl
>>>> + (package
>>>> + (name "r-rbgl")
>>>> + (version "1.49.3")
>>>> + (source (origin
>>>> + (method url-fetch)
>>>> + (uri (string-append
>>>> + "RBGL_" version ".tar.gz"))
>>> Shouldn’t this be “(bioconductor-uri "RBGL" version)”?
>> You are right, it should be “(bioconductor-uri "RBGL" version)”.
> Okay. I’ll make the change before pushing.
If you want I can do the modifications as well and push. Saves you some
valuable time :)
>>>> + (sha256
>>>> + (base32
>>>> + "0rpiqpalbxk82jkwv3l0fimq9y2hrdi0f7ca4v21318541vfsncs"))))
>>>> + (properties
>>>> + `((upstream-name . "RBGL")))
>>>> + (build-system r-build-system)
>>>> + (propagated-inputs
>>>> + `(("r-graph" ,r-graph)))
>>>> + (home-page "http://bioconductor.org/packages/RBGL")
>>>> + (synopsis "Interface to the graph algorithms from Boost")
>>>> + (description
>>>> + "This package provides a fairly extensive and comprehensive
>>>> interface to
>>>> +the graph algorithms contained in the Boost library.")
>>>> + (license license:artistic2.0)))
>>> This package looks very familiar. Chances are that I packaged this
>>> already and forgot about it… :)
>> Do you whether you stripped the Boost source code in this package and
>> used the Boost library from Guix? I wanted to do so, but couldn't
>> figure out how it gets build! Plus, they use Boost 1.61.0 on this RBGL
>> release, and we are stuck at 1.60.0.
> I didn’t try to swap out the sources. In my opinion this should be
> treated as a fork. It’s a subset of Boost with R-specific adaptations.
> Other R packages may depend on this particular “flavour” and might not
> work well otherwise.
> If someone made the effort to change this, it would need to be checked
> each time we updated our Boost package. I don’t think we have the
> infrastructure to keep track of these things, so I’d rather err on the
> side of keeping things as upstream has them.
Right. I didn't compare the original boost sources with the one
provided with the RBGL package, so I didn't know there were differences
I agree to keep the "forked" Boost code instead of using the upstream
Boost code for additional reasons:
1. It makes the package recipe much simpler.
2. It keeps the package as the maintainer of RBGL meant to distribute
it. The compile-time overhead is manageable (building the package on my
machine takes less than ten minutes).
I will take care of upstreaming this package and the other six I proposed.