Summary: | roverlay: recommended packages need "dev-lang/R[minimal]" dependency. | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Benda Xu <heroxbd> |
Component: | Third-Party Tools | Assignee: | André Erdmann <dywi> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | package rule that makes lattice depend on dev-lang/R[minimal] |
Description
Benda Xu
2016-04-27 06:32:24 UTC
Sorry, typo: should be DEPEND=">=dev-lang/R-3.0.0[minimal]" Created attachment 432340 [details]
package rule that makes lattice depend on dev-lang/R[minimal]
If there are only a few packages affected by this issue, then it's doable with a package rule that (1) adds a dependency on dev-lang/R[minimal] and (2) filters out any dep-string that could get resolved as dev-lang/R[-minimal]. (1) is "add DEPEND dev-lang/R[minimal]" in the "ACTION" block of the package rule (2) lattice has "KernSmooth" and "MASS" in the "Suggests" field of its DESCRIPTION file, which get resolved as "dev-lang/R[-minimal]" with the current rule set (specifically, config/simple-deprules.d/R). This would effectively result in a depencency on "dev-lang/R[minimal,-minimal]". This can be circumvented by "depstr_ignore <str>" actions. I've attached a suitable package rule. (In reply to André Erdmann from comment #3) > If there are only a few packages affected by this issue, then it's doable > with a package rule that (1) adds a dependency on dev-lang/R[minimal] and > (2) filters out any dep-string that could get resolved as > dev-lang/R[-minimal]. > > (1) is "add DEPEND dev-lang/R[minimal]" in the "ACTION" block of the package > rule > > (2) lattice has "KernSmooth" and "MASS" in the "Suggests" field of its > DESCRIPTION file, which get resolved as "dev-lang/R[-minimal]" with the > current rule set (specifically, config/simple-deprules.d/R). This would > effectively result in a depencency on "dev-lang/R[minimal,-minimal]". > This can be circumvented by "depstr_ignore <str>" actions. > > I've attached a suitable package rule. For (2), I have a virtual-ebuild solution. Taking KernSmooth as an example: virtual/KernSmooth-0.ebuild: ... RDEPEND=" || ( dev-lang/R[-minimal] sci-CRAN/KernSmooth )" ... and simple-deprules.d/virtual: virtual/KernSmooth :: KernSmooth The virtuals used now cannot encode version. At present any versioned dependencies are resolved by sci-CRAN/KernSmooth. We cannot easily figure out the correspondence of R version to KernSmooth version. This might change in the future when we generate a R-version-recommended-package-versions-mapping database. sci-CRAN/KernSmooth will in turn depend on dev-lang/R[minimal] by (1) same as lattice. With this policy, we have a self-consistant dependency system. By the way, what the command to test the generation of a single package, say sci-CRAN/lattice, without going through the whole CRAN overlay? Hi André, I have made the following update according to your suggestion. --- a/roverlay/package_rules +++ b/roverlay/package_rules @@ -23,6 +23,30 @@ ELSE: rename category s=^(?P<repo>[^-/]+)([-/].*)?$=sci-\g<repo>= END; +# https://bugs.gentoo.org/show_bug.cgi?id=581320 +# recommended packages need "dev-lang/R[minimal]" dependency. + +MATCH: + or + * name boot + * name class + * name cluster + * name codetools + * name foreign + * name KernSmooth + * name lattice + * name MASS + * name Matrix + * name mgcv + * name nlme + * name nnet + * name rpart + * name spatial + * name survival +ACTION: + add DEPEND dev-lang/R[minimal] +END; It does not work cleanly on versioned dependencies, for example, lattice-0.20.33.ebuild is generated as: ... " DEPEND=">=dev-lang/R-3.0.0 dev-lang/R[minimal] " ''' How to make it into DEPEND=">=dev-lang/R-3.0.0[minimal]"? Benda I see. USE-flag aware de-duplication/merging of dependencies needs some coding, I will do that soon. There's no command to process a single package only. However, you can restrict list the input packages with --no-sync and instruct roverlay to replace or revbump the package in question, e.g. "roverlay --no-sync --package-revbump lattice". An alternative to that that does not depend on not syncing is a package rule "match name lattice, then no-op, else do-not-process". I also have a draft for the virtuals, will contact you when it's a pit more polished. Hi André, any updates? Benda Done, pushed upstream. |