R package dependencies, translated into RPM land.
|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
OK; I've been chewing and debating on this with several folks, in several fora, for some time. Here are the facts as I've been able to determine them so far; at least some of them will be stupidly obvious to most of you. Please tear them apart as indicated. + The R community is much sysadmin-y and progammer-y than other language communities. Several positions about correctness which lots of admins take as Truth (i.e. dependency cycle == BAD) they find to be more of an aesthetic call. This is reasonable. + Different repositories in the R community have independant lives and attitudes. There is modest competition and grumbling between maintainers associated with different repos. + Package dependencies cross repo boundaries; sticking with the 'Better' repositories just won't work, and discussion of these variations tends to make R folks testy. conclusion: The goal of evolving the R packages into a DAG is a non-starter. + There are four classes of dependency in R-package land: Requires, Imports, Suggests, and Enhances. + Requires and Imports are required to load the package.  + Suggests may be required to fully CMD CHECK the package  + The need for suggests at CMD CHECK can be deactivated by build config file.  + Many of the dependency cycles can be avoided if we ignore Suggests as an RPM dependency. Now, on to opinion: + We would like all official packages to have passed a full R CMD CHECK + We would like an absolute minimum of manual special case handling. It may not be possible to make that amount zero. So: Here's my suggested procedure for building any single package, gangked from a message I sent to R-core: 1) Express binary package dependencies according to Depends and Imports. I'll call this the 'narrow dependency graph'. 2) As part of the binary package build process, run CHECK with R_CHECK_FORCE_SUGGESTS = false. I'll pull nomenclature out of my ear and call these "built" but not "checked". 3) Build all binary packages which are downstream according to all of Depends, Imports, Suggests, and Extends. I'll call this the 'broad dependency graph'. 4) Install all the packages in the broad dependency graph. 5) for each package in the broad graph, run CHECK with R_CHECK_FORCE_SUGGESTS=true. Then the affected packages are "checked". Perhaps this can be noted with a signature. .... Whew! - Allen S. Rout  http://cran.r-project.org/doc/manuals/R-exts.html#The-DESCRIPTION-file  http://cran.r-project.org/doc/manuals/R-exts.html#Customizing-checking-and-building _______________________________________________ Fedora-r-devel-list mailing list Fedora-r-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-r-devel-list
[Home] [Fedora Users] [Fedora Legacy List] [Fedora Maintainers] [Fedora Desktop] [Red Hat 9 Bible] [Fedora Bible] [Fedora SELinux] [Big List of Linux Books] [Yosemite News] [Yosemite Photos] [KDE Users] [Fedora Tools]