Re: [R-sig-Fedora] Plans for R 4.1 in Fedora?
On Fri, 4 Jun 2021 at 16:08, Iñaki Ucar wrote: > > This seems like a good opportunity to give this a go: > https://github.com/juhp/fbrnch#parallel-building > I did ask for some enhancements for bootstrap builds there, but I don't know how well it works yet. Also, I'm not too sure it understands our virtual Provides/BuildRequires, but if that is added, then it's a good choice for determining build order. > On Fri, 4 Jun 2021 at 21:59, Tom Callaway wrote: >> >> That is a very good point. Oh well. Anyone want to help generate the build >> order? :) >> >> ~spot >> >> On Fri, Jun 4, 2021, 3:57 PM Elliott Sales de Andrade >> wrote: >>> >>> On Fri., Jun. 4, 2021, 10:08 a.m. Tom Callaway, wrote: >>>> >>>> Is there a way to know which R components provide graphics drivers? I would >>>> really rather not rebuild everything if we do not have to. >>>> >>> >>> Unless you mean rebuild for testing purposes, because you added the R(ABI) >>> = major.minor Provides/Requires, you need to rebuild the world anyway. >>> >>>> >>>> >>>> ~spot >>>> >>>> On Sun, May 23, 2021 at 6:28 AM Iñaki Ucar wrote: >>>> >>>> > On Sat, 22 May 2021 at 22:18, José Abílio Matos wrote: >>>> > > >>>> > > Hi all, >>>> > > what should be our plan for R 4.1 update in Fedora? >>>> > >>>> > See [1]. The plan is to wait for the next RStudio release and >>>> > coordinate updates. >>>> > >>>> > [1] https://stat.ethz.ch/pipermail/r-sig-fedora/2021-May/000736.html >>>> > >>>> > > What are the pitfalls and the changes that we should be aware? >>>> > >>>> > The NEWS says: "The graphics engine version, R_GE_version, has been >>>> > bumped to 14 and so packages that provide graphics devices should be >>>> > reinstalled." But anyway, we should do the customary mass rebuild of >>>> > packages to avoid other possible incompatibilities and "Package was >>>> > built under version 4.0" messages. >>>> > >>>> > Iñaki >>>> > >>>> > > The second semester (with the corresponding induced pandemic chaos) >>>> > > is >>>> > > dimming down around here so I have at least time to breath again. :-) >>>> > > >>>> > > FWIW I am in no hurry to have 4.1 in Fedora 34, my main interest is >>>> > > to >>>> > have >>>> > > it in rawhide and later if we find it suitable to backport it to F34. >>>> > > >>>> > > FWIW since our last talk Octave (for version 7 at least) is starting >>>> > > by >>>> > > default to have the major version in the path for packages. :-) >>>> > > >>>> > > Best regards, >>>> > > -- >>>> > > José Abílio >>>> > > [[alternative HTML version deleted]] >>>> > > >>>> > > ___ >>>> > > R-SIG-Fedora mailing list >>>> > > R-SIG-Fedora@r-project.org >>>> > > https://stat.ethz.ch/mailman/listinfo/r-sig-fedora >>>> > >>>> > >>>> > >>>> > -- >>>> > Iñaki Úcar >>>> > >>>> > ___ >>>> > R-SIG-Fedora mailing list >>>> > R-SIG-Fedora@r-project.org >>>> > https://stat.ethz.ch/mailman/listinfo/r-sig-fedora >>>> > >>>> >>>> [[alternative HTML version deleted]] >>>> >>>> ___ >>>> R-SIG-Fedora mailing list >>>> R-SIG-Fedora@r-project.org >>>> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora > > > > -- > Iñaki Úcar -- Elliott ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] Plans for R 4.1 in Fedora?
On Fri., Jun. 4, 2021, 10:08 a.m. Tom Callaway, wrote: > Is there a way to know which R components provide graphics drivers? I would > really rather not rebuild everything if we do not have to. > > Unless you mean rebuild for testing purposes, because you added the R(ABI) = major.minor Provides/Requires, you need to rebuild the world anyway. > > ~spot > > On Sun, May 23, 2021 at 6:28 AM Iñaki Ucar > wrote: > > > On Sat, 22 May 2021 at 22:18, José Abílio Matos > wrote: > > > > > > Hi all, > > > what should be our plan for R 4.1 update in Fedora? > > > > See [1]. The plan is to wait for the next RStudio release and > > coordinate updates. > > > > [1] https://stat.ethz.ch/pipermail/r-sig-fedora/2021-May/000736.html > > > > > What are the pitfalls and the changes that we should be aware? > > > > The NEWS says: "The graphics engine version, R_GE_version, has been > > bumped to 14 and so packages that provide graphics devices should be > > reinstalled." But anyway, we should do the customary mass rebuild of > > packages to avoid other possible incompatibilities and "Package was > > built under version 4.0" messages. > > > > Iñaki > > > > > The second semester (with the corresponding induced pandemic chaos) > is > > > dimming down around here so I have at least time to breath again. :-) > > > > > > FWIW I am in no hurry to have 4.1 in Fedora 34, my main interest is > to > > have > > > it in rawhide and later if we find it suitable to backport it to F34. > > > > > > FWIW since our last talk Octave (for version 7 at least) is starting > by > > > default to have the major version in the path for packages. :-) > > > > > > Best regards, > > > -- > > > José Abílio > > > [[alternative HTML version deleted]] > > > > > > ___ > > > R-SIG-Fedora mailing list > > > R-SIG-Fedora@r-project.org > > > https://stat.ethz.ch/mailman/listinfo/r-sig-fedora > > > > > > > > -- > > Iñaki Úcar > > > > ___ > > R-SIG-Fedora mailing list > > R-SIG-Fedora@r-project.org > > https://stat.ethz.ch/mailman/listinfo/r-sig-fedora > > > > [[alternative HTML version deleted]] > > ___ > R-SIG-Fedora mailing list > R-SIG-Fedora@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-fedora > [[alternative HTML version deleted]] ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] Rebuild against FlexiBLAS
Hi Iñaki, On Mon, 10 Aug 2020 at 08:24, Iñaki Ucar wrote: > > Hi, > > R has been built against FlexiBLAS in rawhide [1, 2]. These are the R > packages that need to be rebuilt: > > ... I noticed that R-sfsmisc is failing on koschei, and it appears to be related to this BLAS change: https://koschei.fedoraproject.org/build/8692462 Any ideas here? > > Could somebody with provenpackager superpowers bump the release and > rebuild them, please? Thanks in advance! > > [1] https://src.fedoraproject.org/rpms/R/pull-request/5 > [2] https://fedoraproject.org/wiki/Changes/FlexiBLAS_as_BLAS/LAPACK_manager > > -- > Iñaki Úcar > -- Elliott ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
On Tue, 21 Jul 2020 at 11:05, José Abílio Matos wrote: > > On Friday, 3 July 2020 18.36.17 WEST Iñaki Ucar wrote: > > Nice! What if we create a group "R" on Pagure and a repo > > "fedora-scripts" or something like that? > > I would like to improve the scripts but FWIW here it comes a rough version of > the script I used. > > The python script loads the csv file and constructs a directed graph and it > starts to remove the leave packages (pruning or trimming if you take a > gardening analogy). > I'm not exactly fluent in Haskell, but Jens Petersen has a tool called fbrnch [1], which is able to calculate the build order, and then submit them, and even handles override for non-Rawhide builds. It does need you to handle some of the bootstrap conditions yourself, but with a defined workflow, it might be possible to request that it handle that too. > The csv files has the dependency of the packages. It is always possible to go > to the packages that remain after the first stage and using a bootstrap mode > to remove most of the dependencies and then to run the code again. > > This procedure was enough to process all the packages. > -- > José Abílio [1] https://github.com/juhp/fbrnch/ -- Elliott ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
On Tue, 7 Jul 2020 at 09:58, José Abílio Matos wrote: > > On Tuesday, 7 July 2020 11.44.48 WEST Iñaki Ucar wrote: > > Try with the CLI (see "man bodhi"): > > > > $ bodhi updates edit --addbuilds > > I found that the best call in this case is instead of --addbuilds to use > --from-tag since then "this will update the builds to the latest ones in the > tag." > Note, if the side tag was turned into an update, you need to tag new builds into f32-updates-candidate first. I've done that for: * R-biomaRt-2.44.0-1.fc32 * R-BiocFileCache-1.12.0-2.fc32 * rpy-3.3.5-1.fc32 > > BTW, could we coordinate to merge this into stable when I finish > > rebuilding stuff in Copr? > > Sure. I am in no rush to submit this to stable. :-) > > -- > José Abílio > -- Elliott ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
On Fri, 3 Jul 2020 at 13:03, José Abílio Matos wrote:
>
> On Monday, 29 June 2020 13.46.02 WEST Iñaki Ucar wrote:
> > But the mass rebuild process is very different, because releng doesn't
> > follow any particular order (they don't need to, because nothing
> > really changed).
> >
> > The question is whether there is any tool to resolve dependencies and
> > generate a list of builds, as I do with the CRAN database, for an
> > arbitrary list of RPMs. That would be perfect. In theory, this should
> > be possible with dnf, but when I tried, I failed (or my script would
> > theoretically work, but it would take ages to complete). I also took a
> > look at releng's repos on Pagure, but I didn't find any tool to do
> > this either.
> >
> > We should bring this to devel, maybe ask Miro and other Python folks
> > who may have The Method(TM), as they are rebuilding stuff on a daily
> > basis.
>
> I think that I meant the way that the python packages are rebuilt for each new
> python version. I should have said Python mass rebuild.
>
> I took your work as the basis, together with Tom's help and I used dnf to get
> a list of R packages (assuming that their name starts with R- ). The advantage
> of this approach is that it works for CRAN and Bioconductor.
>
> $ dnf list available --disablerepo=\* --enablerepo=rawhide-source R-* | tail -
> n +3 | awk -e '{print $1};' | sed -e 's/\.src$//' > r-packages.txt
>
> That gave the list of the (source) packages to rebuild.
>
> In order to get the list of dependencies I used a similar strategy:
> $ (for p in $(cat r-packages.txt); do echo -n $p, ; dnf -q repoquery --
> disablerepo=\* --enablerepo=rawhide-source --requires $p | sed ':a;N;$!ba;s/
> \n/,/g'; done) > r-packages-dependencies.csv
>
> The resulting file is a csv file with the first column as the package and the
> remaining columns as the dependencies.
>
> Now the idea was to process this file using a python script to create a direct
> graph of dependencies (using networkx). In the process non R packages are
> removed and some dependencies are cleaned (e.g. -devel packages direct to the
> source package).
>
>
> The advantage of this is that it allows to identify cycles.
>
> My only surprise in this process was to find that several packages require R-
> rpm-macros.
>
> That causes some dependency cycles because R-rpm-macros also requires
> R-rprintf,R-devel,R-knitr,R-stringi,R-testthat.
>
Your process must have an error, because R-rpm-macros only Requires
R-core. It also BuildRequires nothing.
R-devel depends on R-rpm-macros, and this is intended, in order to
pull in automated dependency generators. If anything else directly
requires R-rpm-macros, that is an error, and these are all in packages
I don't own.
> Since R-rpm-macros is used for Fedora and epel 8 I suggest to remove the
> dependency. Do you agree?
>
>
> --
> José Abílio
>
--
Elliott
___
R-SIG-Fedora mailing list
R-SIG-Fedora@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
Hi José, On Thu, 25 Jun 2020 at 20:05, José Abílio Matos wrote: > > On Friday, 26 June 2020 00.45.46 WEST Elliott Sales de Andrade wrote: > > Thanks for starting off builds. However, please be careful merging to > > master, as some packages were bumped and have incompatibilities that > > should not be put in stable releases. I will try to come up with an > > exact list soon. > > I am doing the process manually to ensure that this does not happen. > Ah, great, thanks for being careful. > Basically my method is for a given package called appropriately pkg: > > cd R-pkg > less R-pkg.spec # read file to ensure that it is safe to build it > > if it is safe then I run: > > $ fedpkg switch-branch f32 && git merge master && git push && fedpkg build -- > target=f32-build-side-24797 && fedpkg switch-branch master; cd .. > > the idea, of course, is that if the merge fails then the case needs to be > dealt manually. > For simple bumps that would not cause any merge issues, as it would just fast-forward. > FWIW most of the credit goes to Tom (spot) since the heavy lifting was already > done. :-) > > I will welcome your list as it becomes easier to find those cases. As I said > before I am doing my best to avoid those cases. It turns out the list is shorter than I expected; I went through their NEWS files to determine which ones are okay: masterf32 RCurl1.98.1.2 1.95.4.12 RSQLite 2.2.0 2.1.2 biglm 0.9.2 0.9.1 digest 0.6.25 0.6.22 fs 1.4.1 1.3.1- was missing dependencies before, I think? gargle 0.5.0 0.4.0 - was missing latest testthat; should be fine to update glue1.4.1 1.3.2 - requires new vctrs; do not bump haven 2.3.0 2.2.0 - requires new vctrs; do not bump httpuv 1.5.41.5.3.1 later 1.1.0.1 1.0.0 lubridate 1.7.8 1.7.4 - should be okay to build 1.7.8, but not 1.7.9, as it needs new vctrs matrixStats0.56.0 0.55.0- there are 'significant changes', but I'm not familiar with this package for whether that's okay multcomp 1.4.13 1.4.12 mvtnorm 1.1.0 1.0.12 pdftools2.3.12.2 - needs new dependencies, but I think check was turned off pkgload 1.1.0 1.0.2 prettyunits 1.1.1 1.0.2 qcc 2.72.2 quantities 0.1.4 0.1.3- should be okay to build 0.1.4, but not 0.1.5, as it needs new vctrs rgdal 1.5.8 1.4.8 rmarkdown 2.22.1 rsvg 2.11.3- probably okay, but missing test dependencies sandwich2.5.1 2.3.0 tidyr 1.1.0 1.0.2- requires new vctrs; do not bump tinytest1.2.1 1.1.0 tinytex 0.23 0.20 vctrs 0.3.0 0.2.4- many breaking changes; do not bump Feel free to double-check these. Also, let me know if you need to stop building and I can do so. > -- > José Abílio > -- Elliott ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
On Thu, 25 Jun 2020 at 19:01, José Abílio Matos wrote: > > On Wednesday, 24 June 2020 10.42.10 WEST Iñaki Ucar wrote: > > Thanks, José and Elliott. I can help with reviews. > > > > I attach here a list of batches of CRAN packages to be rebuilt in > > order (batches separated by a blank line), and the script that > > generates it. Hope it helps. > > > > Iñaki > > R-acepack depends on R-testthat so I moved it the batch after R-testthat. :-) > > If I find a circular dependency I will need to do a bootstrap build. > > Fun lies ahead... :-) Thanks for starting off builds. However, please be careful merging to master, as some packages were bumped and have incompatibilities that should not be put in stable releases. I will try to come up with an exact list soon. > -- > José Abílio > -- Elliott ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
On Wed, 24 Jun 2020 at 05:42, Iñaki Ucar wrote: > > Thanks, José and Elliott. I can help with reviews. > Thanks. I have a few open already: - https://bugzilla.redhat.com/show_bug.cgi?id=1839451 - R-servr - https://bugzilla.redhat.com/show_bug.cgi?id=1839456 - R-filelock - https://bugzilla.redhat.com/show_bug.cgi?id=1839474 - R-DBItest > I attach here a list of batches of CRAN packages to be rebuilt in > order (batches separated by a blank line), and the script that > generates it. Hope it helps. > > Iñaki > > On Wed, 24 Jun 2020 at 11:35, Elliott Sales de Andrade > wrote: > > > > I could do so, but it wouldn't be until this weekend. > > > > Also, Tom mixed in some version bumps to the rebuild, so we'd have to > > check whether those would actually be okay in a released version. I > > would also appreciate some review on new (mostly test) dependencies > > for these bumps. > > > > On Tue, 23 Jun 2020 at 09:43, Iñaki Ucar wrote: > > > > > > Maybe Elliott? > > > > > > On Tue, 23 Jun 2020 at 15:01, Tom Callaway wrote: > > > > > > > > At this point, I simply don't have the time. > > > > > > > > Tom > > > > > > > > On Tue, Jun 23, 2020, 6:06 AM Iñaki Ucar > > > > wrote: > > > >> > > > >> On Tue, 9 Jun 2020 at 10:21, Iñaki Ucar > > > >> wrote: > > > >> > > > > >> > > Given the huge amount of builds (and rebuilds) in this process, I > > > >> > > am > > > >> > > strongly disinclined to attempt this work for Fedora 32 (the idea > > > >> > > of > > > >> > > hundreds of bodhi overrides does not fill me with joy), but I > > > >> > > would not > > > >> > > prevent someone else who wished to try to do so. > > > >> > > > > >> > Note that this is no longer needed. It is possible to use a side tag > > > >> > for F32 too, which is much easier and more appropriate for a massive > > > >> > update like this. > > > >> > > > >> Any plan on doing this in a side tag for F32? I would happily > > > >> volunteer, but I'm not a provenpackager. > > > >> > > > >> -- > > > >> Iñaki Úcar > > > >> > > > >> ___ > > > >> R-SIG-Fedora mailing list > > > >> R-SIG-Fedora@r-project.org > > > >> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora > > > > > > > > > > > > -- > > > Iñaki Úcar > > > > > > > > -- > > Elliott > > > > -- > Iñaki Úcar -- Elliott ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0 rebuild status
I could do so, but it wouldn't be until this weekend. Also, Tom mixed in some version bumps to the rebuild, so we'd have to check whether those would actually be okay in a released version. I would also appreciate some review on new (mostly test) dependencies for these bumps. On Tue, 23 Jun 2020 at 09:43, Iñaki Ucar wrote: > > Maybe Elliott? > > On Tue, 23 Jun 2020 at 15:01, Tom Callaway wrote: > > > > At this point, I simply don't have the time. > > > > Tom > > > > On Tue, Jun 23, 2020, 6:06 AM Iñaki Ucar wrote: > >> > >> On Tue, 9 Jun 2020 at 10:21, Iñaki Ucar wrote: > >> > > >> > > Given the huge amount of builds (and rebuilds) in this process, I am > >> > > strongly disinclined to attempt this work for Fedora 32 (the idea of > >> > > hundreds of bodhi overrides does not fill me with joy), but I would not > >> > > prevent someone else who wished to try to do so. > >> > > >> > Note that this is no longer needed. It is possible to use a side tag > >> > for F32 too, which is much easier and more appropriate for a massive > >> > update like this. > >> > >> Any plan on doing this in a side tag for F32? I would happily > >> volunteer, but I'm not a provenpackager. > >> > >> -- > >> Iñaki Úcar > >> > >> ___ > >> R-SIG-Fedora mailing list > >> R-SIG-Fedora@r-project.org > >> https://stat.ethz.ch/mailman/listinfo/r-sig-fedora > > > > -- > Iñaki Úcar -- Elliott ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] R 4.0.0
On Tue, 12 May 2020 at 12:13, Tom Callaway wrote: > > Okay, I'm convinced. > > https://github.com/rpm-software-management/R-rpm-macros/pull/1 > I merged the PR and pushed it to dist-git as well. I have not built anything though, since as I mentioned in the PR, I think builds should be done in a side tag to avoid breakage. > Thanks, > Tom > > On Mon, May 11, 2020 at 11:48 AM Iñaki Ucar wrote: > > > On Mon, 11 May 2020 at 16:29, Tom Callaway wrote: > > > > > > Hmmm. That seems like a rather heavy dependency, given that I think we've > > > only been forced to do rebuilds for everything as a result of 4.0.0 and > > > 3.4.0. > > > > That's just coincidence, because if you browse old NEWS, you can see > > "packages [doing this or that] need to be re(-)installed" here and > > there if most minor versions: maybe there wasn't any of such packages > > in Fedora, maybe a mass rebuild or an update fixed the issue before > > anyone noticed... It's just that we don't have any mechanism to detect > > that unless a user complains. > > > > > Does anyone know if upstream has any sort of commitment to ABI here that > > we > > > could depend on (e.g. only breaking on major versions, never minor) ? > > > > AFAIK, there's this commitment only for patch versions. In fact, the > > path for the personal library is: > > > > ~/R/x86_64-redhat-linux-gnu-library/./ > > > > so, when you install a new minor version, you don't have any package > > in your personal library. Most of the time, for many packages, it just > > works if you copy the old packages into the new folder, but many times > > things break and reinstallation is needed. And this may happen for > > compiled packages, but also for non-compiled ones (e.g.: "Packages > > defining S4 classes with the above S3/S4 classes as slots should be > > reinstalled", in R 3.3.0). > > > > So maybe we should streamline mass rebuild of R packages, and do it > > for all minor updates. The virtual provide you proposed will force us > > to do that, and will prevent breakages and complaints. > > > > -- > > Iñaki Úcar > > > > > > [[alternative HTML version deleted]] > > ___ > R-SIG-Fedora mailing list > R-SIG-Fedora@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-fedora -- Elliott ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
[R-sig-Fedora] Removing macros.R
Hi, (This message is cross-posted to the Fedora devel and R SIG Fedora mailing lists.) Currently, R-core installs macros.R which defines one macro: %_R_make_search_index /usr/lib/rpm/R-make-search-index.sh This script does nothing, and there is no mention of this macro in our guidelines. The macro is used by one package, R-systemfit. The script is not used. According to the R %changelog, it was disabled in 2009. I would like to clean this up, and will do so in approximately a week, and/or whenever the mass rebuild finishes. -- Elliott ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
Re: [R-sig-Fedora] Fwd: Fedora 31 System-Wide change proposal: Automatic R runtime dependencies
On Thu, 4 Jul 2019 at 06:05, José Abílio Matos wrote: > > On Thursday, 4 July 2019 10.35.18 WEST Elliott Sales de Andrade wrote: > > FYI, I plan on implementing this for F31 if no issues arise. > > Are there are any R packages, other than those built in R itself, that are not > affected by this change? :-) > Oh, actually, I forgot to mention R in that list... > Because I think that in this case the list of affected packages would be all > the packages with R subpackages. Or am I misunderstanding the details? > Yes, it is all packages with R subpackages. There are no required changes to the specs, just a rebuild, unless FPC mandates removing duplicate Requires. > BTW nice job. :-) > > Best regards, > -- > José Abílio > > ___ > R-SIG-Fedora mailing list > R-SIG-Fedora@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-fedora -- Elliott ___ R-SIG-Fedora mailing list R-SIG-Fedora@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-fedora
[R-sig-Fedora] Fwd: Fedora 31 System-Wide change proposal: Automatic R runtime dependencies
FYI, I plan on implementing this for F31 if no issues arise. -- Forwarded message - From: Ben Cotton Date: Tue, 2 Jul 2019 at 10:55 Subject: Fedora 31 System-Wide change proposal: Automatic R runtime dependencies To: , Development discussions related to Fedora https://fedoraproject.org/wiki/Changes/Automatic_R_runtime_dependencies == Summary == Packages of R libraries will produce a standard R(packageName) Provides, and Requires on these standard names will be added from library metadata. Standard provides will use the unmodified versions from the metadata. Suggested dependencies will not be automatically added, but can be opted in by the packager. == Owner == * Name: [[User:qulogic| Elliott Sales de Andrade]] * Email: quantum.anal...@gmail.com == Detailed Description == R libraries currently provide metadata indicating runtime requirements on other libraries in a DESCRIPTION file. Using RPM's file attributes and dependency generator support, these requirements can be added to packages automatically. These will use namespaced Provides of R(packageName) = packageVersion where packageName is the importable name of the package and packageVersion is the upstream version (note: upstream versions are often sanitized for Fedora since RPM cannot use dashes in versions.) R library metadata includes Depends and Imports which will be mapped to Requires. Metadata that specifies Enhances will be mapped directly to Enhances. Metadata that specifies Suggests will ''not'' be mapped to anything by default. Oftentimes, suggested libraries are used to indicate dependencies that are needed at build time only. Packagers who wish to include any actual runtime Suggests may opt in to adding them using a (TBD) flag or just continue to add Suggests manually. == Benefit to Fedora == This change provides a standard Provided name for R packages. This change helps users of R packages by providing the ''original'' version value (as opposed to the sanitized one for RPM.) This change reduces the amount of work packagers need to do keeping (R package) dependencies correct. == Scope == * Proposal owners: The automated dependency generator is [https://src.fedoraproject.org/fork/qulogic/rpms/R/blob/autodeps/f/R-deps.R available], but will need to be updated to provide the opt-in Suggests. The generator and file attributes will likely be housed in the RPM organization, and a new package will be created for it. R packages will need to be rebuilt after the generator is packaged, in order to ensure that they contain the new Provides. If the mass rebuild is not sufficient, this will be carried out in a side tag. * Other developers: Others are welcome to rebuild their packages once the generators are available, but it is not a requirement. * Release engineering: [https://pagure.io/releng/issue/8501 Releng issue 8501] * Policies and guidelines: R packaging guidelines should be updated to mention the new generator; this can be done after the implementation is done. * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == No impact expected. == How To Test == # Pick any R package in Fedora. # Attempt to install it. # Verify that automatic dependencies are correct, i.e., the package installed without missing dependencies, and the dependencies that were pulled in are the ones specified in its DESCRIPTION file. == User Experience == Users interested in R may install packages based on upstream's ''real'' version, and missing dependency annotations will be less likely to occur. == Dependencies == Move of code to RPM organization; it would be preferred to occur as early as possible, but is not a full blocker. These packages will need to be rebuilt: * COPASI * R-abind * R-acepack * R-affy * R-affydata * R-affyio * R-ALL * R-AnnotationDbi * R-ape * R-argon2 * R-ascii * R-askpass * R-assertthat * R-AUC * R-backports * R-base64enc * R-Bessel * R-BH * R-biglm * R-bindr * R-bindrcpp * R-Biobase * R-BiocGenerics * R-BiocParallel * R-biomaRt * R-Biostrings * R-bit * R-bit64 * R-bitops * R-blob * R-brew * R-BSgenome * R-BSgenome.Celegans.UCSC.ce2 * R-BufferedMatrix * R-BufferedMatrixMethods * R-Cairo * R-callr * R-car * R-caTools * R-cellranger * R-chron * R-cli * R-cliapp * R-clipr * R-clisymbols * R-coda * R-colorspace * R-combinat * R-commonmark * R-corpus * R-crayon * R-curl * R-data.table * R-date * R-DBI * R-dbplyr * R-debugme * R-DelayedArray * R-deldir * R-desc * R-dichromat * R-diffobj * R-digest * R-disposables * R-doParallel * R-dplyr * R-dtplyr * R-DynDoc * R-ellipsis * R-errors * R-evaluate * R-expm * R-fansi * R-farver * R-fastmatch * R-fibroEset * R-filehash * R-FMStable * R-foghorn * R-fontBitstreamVera * R-fontLiberation * R-forcats * R-foreach * R-formatR * R-fortunes * R-fs * R-fts * R-futile.logger * R-futile.options * R-future * R-gamlss.dist * R-gapminder * R-gdata * R-gdtools * R-gee * R-geepack * R-generics * R-GenomeInfoDb * R-GenomeInfoDbData * R
