WRT https://fedoraproject.org/wiki/Changes/Automatic_R_runtime_dependencies I would like to clarify one thing with the Guidelines. I can open a guidelines change PR once that is decided.
As part of this Change, packages of R libraries will have Requires and Suggests on a standardized name. It was pointed out in the discussions that even weak dependencies must be satisfiable from Fedora repos. Since R libraries do not differentiate from runtime weak dependencies (i.e., more functionality) and build-time weak dependencies (i.e., docs, tests, etc.), there tend to be a lot of them that are unpackaged.
Requires
Suggests
So the question is how to best handle Suggests on R packages:
Provides
Any one of these is straightforward to do; I just don't want to pick on FPC won't like.
I think we need to revisit our phrasing… seems to be too strong. I don't remember original point why it has been chosen to do this (please let me know)…
All package dependencies (build-time or runtime, regular, weak or otherwise) MUST ALWAYS be satisfiable within the official Fedora repositories.
Packages MUST build and install correctly and function (whatever that means) using packages only from official Fedora repositories. Packagers SHOULD NOT use dependencies which might pull 3rd-party packages without strong reason.
RPM can automatically determine dependencies for most compiled libraries and for some scripting languages such as Perl. Automatically determined dependencies MUST NOT be duplicated by manual dependencies.
RPM can automatically determine dependencies for most compiled libraries and for many other scripts and programming languages (check their pages in Packaging Guidelines). Automatically determined dependencies MUST NOT be duplicated by manual dependencies.
Build dependencies, however, cannot be automatically determined and MUST be explicitly listed. Refer to the Build-Time Dependencies (BuildRequires).
Build dependencies can be generated starting with Fedora 31 and SHOULD be used if corresponding code exists to generate those dependencies. Dependencies which can not be automatically determined, MUST be explicitly listed. Refer to …
Versioned dependencies (build-time or runtime) SHOULD ONLY be used when actually necessary to guarantee that the proper version of a package is present. If a versioned dependency would be satisfied by a version present in three previous Fedora releases then the then a versioned dependency is not needed and a regular unversioned dependency SHOULD be used instead.
Versioned dependencies SHOULD be used when actually necessary to guarantee that the proper version of a package is present (e.g. setup.py defines version constraint).
A versioned dependency on a package with a defined Epoch MUST be included in that dependency. Otherwise the dependency will not function as expected.
A version dependency on a package name with a defined Epoch MUST be included in that dependency. Otherwise the dependency will not function as expected. Packages which rely on a package provide do not need Epoch.
So I would say that Suggests are entirely okay in this context. Let's see opinion of other FPC members on my text above.
Metadata Update from @ignatenkobrain: - Issue tagged with: meeting
Yeh, auto adding suggests is fine as long as all the auto adds. refer to Fedora packages. If there's some reason that isn't true I think the only option is to turn them off.
Since this wasn't discussed at the meeting yet, I thought I'd get some stats to help decide things.
There are 334 R packages in Fedora, specifying 1626 BuildRequires, 1247 Requires, 1 Recommends, and 399 Suggests on other R packages. Only 352 of those Suggests are for valid packages. The other 47 point to 37 unpackaged items.
Looking at the actual CRAN metadata for packages, there are 1019 Suggests with 831 valid ones. The remaining 188 point to 88 unpackaged items.
So turning on auto-Suggests would add 141 new unfulfilled Suggests on 51 unpackaged libraries.
If auto-Suggests should be disabled by default, I'd still like a way for packagers to opt-in (so that it uses the standard name and correctly grabs any version requirements); is there a preference for naming/implementation for that?
We talked about this at last weeks meeting:
https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2019-08-01/fpc.2019-08-01-16.00.txt
So looking at it a bit closer, it appears that RPM does provide proper controls for excluding automated Suggests; they just aren't explicitly documented.
This of course makes things a lot easier, since I don't have to implement anything and (perhaps most importantly), I don't need to come up with a name for it suitable for everyone.
We've had some conversation about this on the Flock with @spot, so let's keep this on hold for now.
To clarify, what I mean is that this option:
was a lot less work than I expected and easily implemented. So while I would like to know FPC's stance on dangling Suggests, I don't need to know with any particular urgency (not that there was much before.)
We talked about this issue this week:
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-09-26/fpc.2019-09-26-16.00.html
Well, it follows the same principle of https://docs.fedoraproject.org/en-US/packaging-guidelines/AutoProvidesAndRequiresFiltering/#_filtering_provides_and_requires_after_scanning and https://rpm.org/user_doc/dependency_generators.html#tweaking-dependency-generators except that RPM docs don't point out that you can use suggests or enhances in place of requires in those filters.
suggests
enhances
requires
So like perl in the above link, you can do, e.g, %global __suggests_exclude ^R\\(ggforce\\) or to exclude multiple, %global __suggests_exclude ^R\\((mapdata|maptools|rnaturalearth)\\).
perl
%global __suggests_exclude ^R\\(ggforce\\)
%global __suggests_exclude ^R\\((mapdata|maptools|rnaturalearth)\\)
I've updated the docs in #919 to show some examples.
I think the PR is basically ready to be merged. However, I wonder if the "Automatically generated dependencies section" is actually true for all Fedora releases. I don't think it applies to F29 or F30 as R-rpm-macros doesn't exist there. (It was built but not pushed.) The guidelines should cover all live Fedora releases, so if something there doesn't apply everywhere then that needs to be noted.
I've added an admonition about this. R-rpm-macros is not expected to be pushed to <F31.
R-rpm-macros
I've merged PR #919 so I guess this is ready to go. Though now I'm concerned that I might have been a bit too quick. I thought this had all been approved but scrolling back through the ticket.... I don't see where it was.
Oops.
Other FPC folks, if this is a problem, please push a revert or let me know and I'll push a revert. Or we can take a vote. Obviously I'm +1 now that the issues we have have been resolved (to my satisfaction, at least).
@tibbs I think the "does this work on all releases" question was the last thing that blocked us from accepting this.
So, if we actually want to still count votes after the fact, I'm +1 as well :thumbsup:
Sorry this took so long to follow up, but you know, lawyers.
We cannot have weak dependencies which refer to packages which are not in Fedora.
@spot can you be more explicit in the wording please? We can't have dependencies which refer known(?) packages (or their provides?) which are not in Fedora?
What about if package was in Fedora but got removed or something like that so technically package does not meet this criteria?
My phrasing was intentional. We cannot have weak dependencies which refer to packages which are not in Fedora.
If a package got removed from Fedora, we cannot have a weak dependency on it. If someone wants a weak dependency, that dependent package needs to be in Fedora.
From a legal perspective, we have an understood level of risk about the packages in Fedora, and we have no capacity to have a similar level of understanding about packages that are not in Fedora.
FWIW, I do realize this makes weak dependencies pretty pointless in Fedora.
@spot so that means we should ask rel-eng to stop shipping any packages which refer to packages (requirements) not provided by Fedora. Do I understand it correctly?
Yes.
This is not a "do this immediately or the lawyers drop in from black helicopters", but we should be actively working to resolve any situations where we have weak dependencies on packages not in Fedora.
@spot thanks for the feedback, I'll open necessary tickets for FESCo and Release Engineering.
One more question about BuildRequires. Those are stored as Requires in .src.rpm. At some point we might drop package which was used to build it. Imagine having BuildRequires: python2-pytest and it was dropped. However, package still works and is being shipped. What should we do in this case?
Also, just want to note that there are 2 types of weak dependencies: Recommends and Suggests. Also this applies for non-weak dependencies, talking about Requires here.
Right?
If package foo has a BuildRequires on python2-pytest, and python2-pytest is removed from Fedora, it will no longer rebuild from source and will get flagged (eventually) as FTBFS. Nevertheless, this issue is not a concern with regards to this specific guidance, because BuildRequires is not a weak dependency.
Since the dependency resolvers treat Recommends like Requires, we treat them that way from a legal perspective. Suggests is a true weak dependency, since the package can install via dnf even if the Suggests is not found.
The underlying philosophy we have always had does not change with this. Packages in Fedora need to be installable using dependencies found within Fedora. This just provides additional clarification that we cannot have Suggests which point outside of Fedora.
If that's not clear, keep asking questions, please. :)
I think that's pretty much clear :) No Requires, Recommends, Suggests can point to something what is not in Fedora.
Btw, what about Supplements and Enchances? That's reverse weak dependencies.
Those would be in external packages, where we have no control over what they do.
Usually yes, but in theory it is possible to put them in Fedora (like Fedora package would add some feature to the 3rd party package).
Okay. The answer is still no. We cannot have weak dependencies which refer to packages which are not in Fedora. Reverse or normal makes no difference.
Thanks. And probably last question from me: "in Fedora" means "same release in question" or "whether it was ever shipped with Fedora"?
Okay, just making sure I understand. The scenario is this:
Package foo (in Fedora) has a weak dependency on bar (Suggests: bar). bar is in Fedora 31, but dies off in Fedora 32 (either because it has some reason that it can no longer stay in Fedora or is simply abandoned/retired).
In that scenario, package foo is still fine in Fedora 31, but cannot stay as-is in Fedora 32, without removing the Suggests: bar.
yes, that's what I meant.
All this sounds nuts, but I completely understand the reasoning and I'll try to help with implementation to enforce these rules.
Let me know if there is anything else I can do to help here.
This is not a "do this immediately or the lawyers drop in from black helicopters"
I am so glad.
Technically, we have plenty of broken deps in Fedora. There was never a strong enough argument to deal with them, but now we know they are illegal, it will make things much funnier.
Instead of: "Package foo fails to install, no package provides bar" I shall open "Package foo is illegal, no package provides bar" :D
Some other serious question thou:
Is it legal for me to commit/push a change that removes such illegal requirement, or would that imply I was aware of the illegal dependency in the first place and hence I'd rather not touch it and report it to Fedora legal instead?
Do we need to dump all the illegal requirements from our git histories when we retire a Fedora package?
I want to be clear, the concern raised here is specifically around a user installing a Fedora package and receiving another package from outside of the Fedora package tree via a weak dependency.
Fedora packages with broken hard dependencies can't be installed at all, so while we should absolutely clean that situation up, that is not a legal concern. We already disallow Fedora packages from having hard dependencies from outside of the Fedora package tree.
I will now try to answer your questions.
If you see a Fedora package which has a weak-dependency on a package which is not found in the Fedora package tree, you can commit/push a change to remove this weak-dependency. If, for any reason, you are uncomfortable taking this action, you can file a bug and block FE-Legal (or email legal@fedoraproject.org).
Your phrasing here is disingenuous, but no, if a package is being retired, it does not need to have its git history altered.
Being disingenuous was not my intention. Sorry about that.
I am genuinely confused that a week dependency on a package is considered legally bad, but not a strong dependency.
The concern is in directing users to packages that are not part of the Fedora package tree. We have an understood level of risk about the packages in Fedora, and we have no capacity to have a similar level of understanding about packages that are not in Fedora.
Scenario 1: Fedora package chromium has a Suggests: aardvark. aardvark is not in Fedora. This package will install if only Fedora repos are enabled. However, if a user installs chromium, and they have a third-party repo enabled that provides aardvark, they will end up with aardvark installed. Since the Fedora package "suggested" aardvark, if aardvark does something legally questionable, we could be liable for inducing users to take that action. Since aardvark is not in Fedora, it is not under our control in any way.
Scenario 2: Fedora package chromium has a Requires: aardvark. aardvark is not in Fedora. This package will not install without some third-party repo providing aardvark. Fedora does not permit packages to have Requires which are not found in Fedora.
I suppose that if someone had a package that was in violation of the guidelines and had a Requires to a package not found in Fedora, it is plausible that it could have a similar degree of risk, but that is one of the reason we have that rule in the first place.
However, if a user installs chromium, and they have a third-party repo enabled that provides aardvark, they will end up with aardvark installed. Since the Fedora package "suggested" aardvark, if aardvark does something legally questionable, we could be liable for inducing users to take that action. Since aardvark is not in Fedora, it is not under our control in any way.
No, that's not true. Suggests are not getting installed automatically, neither shown anywhere. They are only taken into account for the package preference. If chromium Requires: foo and that is provided by aardvark and aaa (former is not in Fedora), then if you have that 3rd-party repo enabled, then it will be pulled instead of aaa.
chromium
aardvark
aaa
Are you saying that if:
Fedora package chromium has:
# aardvark is not in Fedora Suggests: aardvark
and a user has a third party repo which has aardvark in it, and that user does dnf install chromium, they will not also get aardvark installed via dnf?
that is correct
@spot that's exactly what I am saying. Just note that there are 2 types of forward weak dependencies: Recommends and Suggests. Former does pull in packages automatically, latter is used only for prioritizing "alternatives" (dependencies which are equal to SAT solver).
Okay, that's a nuance that is interesting, but it does not change the guidance.
We'd never want to suggest to the depsolver that it ever prefer a package not found in Fedora.
Also I have to note one more thing which is interesting, but probably irrelevant to the guidance: If your package Requires: foo and that is provided by bar (from 3rd-party) and baz (from Fedora), the former one will win in solver (obviously if those are considered as "alternatives"). That is due to the alphabet sorting.
Requires: foo
bar
baz
This is the part that confuses me in scenario 2:
Scenario 2: Fedora package chromium has a Requires: aardvark. aardvark is not in Fedora. This package will not install without some third-party repo providing aardvark. However, if a user installs chromium, and they have a third-party repo enabled that provides aardvark, they will end up with aardvark installed. Since the Fedora package "required" aardvark, if aardvark does something legally questionable, we could be liable for inducing users to take that action. Since aardvark is not in Fedora, it is not under our control in any way.
Technically the only difference I see between scenario 1 (when reading suggests as recommends to avoid the nuance pointed out by @ignatenkobrain) and scenario 2 is what happens when a 3rd party repo with aardvark is not enabled. When it is, the situation is entirely identical: aardvark is pulled in.
Either way, Fedora does not permit packages to have any kind of dependency on packages which are not found in Fedora. It just confuses me that with a "weak" dependency, this is for legal reasons, while with "strong", it is not.
There are legal concerns about a Fedora package having a hard dependency on a package not found in Fedora. There are also practical concerns about this scenario (cannot install package).
Thanks.
I agree. This is interesting but not relevant to the guidance here. In this situation, we are not pointing to something outside of Fedora. We are pointing to a package in Fedora which provides foo.
Another possibly interesting fact is that we have (x86_64 rawhide):
I've used this script by @ignatenkobrain:
import itertools import solv pool = solv.Pool() pool.setarch('x86_64') repo = pool.add_repo('rawhide') # sudo dnf --repo=rawhide makecache f = solv.xfopen('/var/cache/dnf/rawhide.solv') repo.add_solv(f) f.close() pool.createwhatprovides() for s in pool.solvables: deps = set() for k in (solv.SOLVABLE_RECOMMENDS, solv.SOLVABLE_SUGGESTS): deps.update(set(s.lookup_deparray(k))) for dep in deps: if not pool.whatprovides(dep): print(f'{s}\t{dep}')
That's interesting, but not surprising given how we've had basically no reporting about broken dependencies for ages now. Every one of those broken dependencies is simply something that needs fixing. Sadly it's just going to take a lot of work.
Note that the implication here is strong that these issues need to be fixed in all live Fedora releases, not just rawhide, if at all possible. So there's much more work to do and the time window for fixing things in F29 is shrinking somewhat quickly.
And just to add something which is relevant to the topic of R packaging, here are the problematic dependencies of current R packages in rawhide (according to a modified version of the above script):
R-BiocParallel-1.16.5-3.fc31.x86_64 Suggests: R(ShortRead) R-BiocParallel-1.16.5-3.fc31.x86_64 Suggests: R(BBmisc) R-BiocParallel-1.16.5-3.fc31.x86_64 Suggests: R(BatchJobs) R-BiocParallel-1.16.5-3.fc31.x86_64 Suggests: R(VariantAnnotation) R-BiocParallel-1.16.5-3.fc31.x86_64 Suggests: R(batchtools) R-BiocParallel-1.16.5-3.fc31.x86_64 Suggests: R(data.table) R-BiocParallel-1.16.5-3.fc31.x86_64 Suggests: R(Rmpi) R-BiocParallel-1.16.5-3.fc31.x86_64 Suggests: R(BiocStyle) R-BiocParallel-1.16.5-3.fc31.x86_64 Suggests: R(BiocGenerics) R-BiocParallel-1.16.5-3.fc31.x86_64 Suggests: R(GenomicRanges) R-BiocParallel-1.16.5-3.fc31.x86_64 Suggests: R(RNAseqData.HNRNPC.bam.chr14) R-BiocParallel-1.16.5-3.fc31.x86_64 Suggests: R(TxDb.Hsapiens.UCSC.hg19.knownGene) R-DBI-1.0.0-5.fc31.noarch Suggests: R(covr) R-DelayedArray-0.4.1-5.fc31.noarch Suggests: R(HDF5Array) R-DelayedArray-0.4.1-5.fc31.noarch Suggests: R(BiocGenerics) R-DelayedArray-0.4.1-5.fc31.noarch Suggests: R(airway) R-DelayedArray-0.4.1-5.fc31.noarch Suggests: R(genefilter) R-DelayedArray-0.4.1-5.fc31.noarch Suggests: R(BiocStyle) R-DelayedArray-0.4.1-5.fc31.noarch Suggests: R(IRanges) >= 2.11.17 R-DelayedArray-0.4.1-5.fc31.noarch Suggests: R(pryr) R-GenomeInfoDb-1.16.0-5.fc31.noarch Suggests: R(BiocGenerics) >= 0.13.8 R-GenomeInfoDb-1.16.0-5.fc31.noarch Suggests: R(BSgenome) R-GenomeInfoDb-1.16.0-5.fc31.noarch Suggests: R(BSgenome.Celegans.UCSC.ce2) R-GenomeInfoDb-1.16.0-5.fc31.noarch Suggests: R(BSgenome.Hsapiens.NCBI.GRCh38) R-GenomeInfoDb-1.16.0-5.fc31.noarch Suggests: R(BSgenome.Scerevisiae.UCSC.sacCer2) R-GenomeInfoDb-1.16.0-5.fc31.noarch Suggests: R(BiocStyle) R-GenomeInfoDb-1.16.0-5.fc31.noarch Suggests: R(GenomicRanges) R-GenomeInfoDb-1.16.0-5.fc31.noarch Suggests: R(IRanges) >= 2.13.12 R-GenomeInfoDb-1.16.0-5.fc31.noarch Suggests: R(TxDb.Dmelanogaster.UCSC.dm3.ensGene) R-GenomeInfoDb-1.16.0-5.fc31.noarch Suggests: R(GenomicFeatures) R-GenomicAlignments-1.18.1-3.fc31.x86_64 Suggests: R(GenomicRanges) >= 1.33.4 R-GenomicAlignments-1.18.1-3.fc31.x86_64 Suggests: R(BSgenome) R-GenomicAlignments-1.18.1-3.fc31.x86_64 Suggests: R(ShortRead) R-GenomicAlignments-1.18.1-3.fc31.x86_64 Suggests: R(BSgenome.Dmelanogaster.UCSC.dm3) R-GenomicAlignments-1.18.1-3.fc31.x86_64 Suggests: R(BiocStyle) R-GenomicAlignments-1.18.1-3.fc31.x86_64 Suggests: R(DESeq2) R-GenomicAlignments-1.18.1-3.fc31.x86_64 Suggests: R(pasillaBamSubset) R-GenomicAlignments-1.18.1-3.fc31.x86_64 Suggests: R(Biostrings) >= 2.47.6 R-GenomicAlignments-1.18.1-3.fc31.x86_64 Suggests: R(BiocGenerics) >= 0.15.3 R-GenomicAlignments-1.18.1-3.fc31.x86_64 Suggests: R(BSgenome.Hsapiens.UCSC.hg19) R-GenomicAlignments-1.18.1-3.fc31.x86_64 Suggests: R(IRanges) >= 2.15.12 R-GenomicAlignments-1.18.1-3.fc31.x86_64 Suggests: R(RNAseqData.HNRNPC.bam.chr14) R-GenomicAlignments-1.18.1-3.fc31.x86_64 Suggests: R(TxDb.Dmelanogaster.UCSC.dm3.ensGene) R-GenomicAlignments-1.18.1-3.fc31.x86_64 Suggests: R(TxDb.Hsapiens.UCSC.hg19.knownGene) R-GenomicAlignments-1.18.1-3.fc31.x86_64 Suggests: R(GenomicFeatures) R-GenomicAlignments-1.18.1-3.fc31.x86_64 Suggests: R(edgeR) R-R6-2.2.2-5.fc31.noarch Suggests: R(pryr) R-RSQLite-2.1.1-6.fc31.x86_64 Suggests: R(DBItest) R-Rcpp-1.0.2-1.fc32.i686 Suggests: R(pinp) R-Rcpp-1.0.2-1.fc32.i686 Suggests: R(rbenchmark) R-Rcpp-1.0.2-1.fc32.i686 Suggests: R(pkgKitten) >= 0.1.2 R-Rcpp-1.0.2-1.fc32.x86_64 Suggests: R(pinp) R-Rcpp-1.0.2-1.fc32.x86_64 Suggests: R(rbenchmark) R-Rcpp-1.0.2-1.fc32.x86_64 Suggests: R(pkgKitten) >= 0.1.2 R-Rsamtools-1.34.1-3.fc31.i686 Suggests: R(GenomicFeatures) R-Rsamtools-1.34.1-3.fc31.i686 Suggests: R(KEGG.db) R-Rsamtools-1.34.1-3.fc31.i686 Suggests: R(TxDb.Hsapiens.UCSC.hg18.knownGene) R-Rsamtools-1.34.1-3.fc31.i686 Suggests: R(BiocStyle) R-Rsamtools-1.34.1-3.fc31.i686 Suggests: R(Biostrings) >= 2.47.6 R-Rsamtools-1.34.1-3.fc31.i686 Suggests: R(BSgenome.Hsapiens.UCSC.hg19) R-Rsamtools-1.34.1-3.fc31.i686 Suggests: R(IRanges) >= 2.13.12 R-Rsamtools-1.34.1-3.fc31.i686 Suggests: R(RNAseqData.HNRNPC.bam.chr14) R-Rsamtools-1.34.1-3.fc31.i686 Suggests: R(TxDb.Dmelanogaster.UCSC.dm3.ensGene) R-Rsamtools-1.34.1-3.fc31.i686 Suggests: R(BiocGenerics) >= 0.25.1 R-Rsamtools-1.34.1-3.fc31.i686 Suggests: R(GenomicRanges) >= 1.31.8 R-Rsamtools-1.34.1-3.fc31.i686 Suggests: R(ShortRead) >= 1.19.10 R-Rsamtools-1.34.1-3.fc31.x86_64 Suggests: R(GenomicFeatures) R-Rsamtools-1.34.1-3.fc31.x86_64 Suggests: R(KEGG.db) R-Rsamtools-1.34.1-3.fc31.x86_64 Suggests: R(TxDb.Hsapiens.UCSC.hg18.knownGene) R-Rsamtools-1.34.1-3.fc31.x86_64 Suggests: R(BiocStyle) R-Rsamtools-1.34.1-3.fc31.x86_64 Suggests: R(Biostrings) >= 2.47.6 R-Rsamtools-1.34.1-3.fc31.x86_64 Suggests: R(BSgenome.Hsapiens.UCSC.hg19) R-Rsamtools-1.34.1-3.fc31.x86_64 Suggests: R(IRanges) >= 2.13.12 R-Rsamtools-1.34.1-3.fc31.x86_64 Suggests: R(RNAseqData.HNRNPC.bam.chr14) R-Rsamtools-1.34.1-3.fc31.x86_64 Suggests: R(TxDb.Dmelanogaster.UCSC.dm3.ensGene) R-Rsamtools-1.34.1-3.fc31.x86_64 Suggests: R(BiocGenerics) >= 0.25.1 R-Rsamtools-1.34.1-3.fc31.x86_64 Suggests: R(GenomicRanges) >= 1.31.8 R-Rsamtools-1.34.1-3.fc31.x86_64 Suggests: R(ShortRead) >= 1.19.10 R-S4Vectors-0.22.0-2.fc31.i686 Suggests: R(BiocGenerics) >= 0.23.3 R-S4Vectors-0.22.0-2.fc31.i686 Suggests: R(ShortRead) R-S4Vectors-0.22.0-2.fc31.i686 Suggests: R(BiocStyle) R-S4Vectors-0.22.0-2.fc31.i686 Suggests: R(GenomicRanges) R-S4Vectors-0.22.0-2.fc31.i686 Suggests: R(IRanges) R-S4Vectors-0.22.0-2.fc31.i686 Suggests: R(graph) R-S4Vectors-0.22.0-2.fc31.i686 Suggests: R(data.table) R-S4Vectors-0.22.0-2.fc31.x86_64 Suggests: R(BiocGenerics) >= 0.23.3 R-S4Vectors-0.22.0-2.fc31.x86_64 Suggests: R(ShortRead) R-S4Vectors-0.22.0-2.fc31.x86_64 Suggests: R(BiocStyle) R-S4Vectors-0.22.0-2.fc31.x86_64 Suggests: R(GenomicRanges) R-S4Vectors-0.22.0-2.fc31.x86_64 Suggests: R(IRanges) R-S4Vectors-0.22.0-2.fc31.x86_64 Suggests: R(graph) R-S4Vectors-0.22.0-2.fc31.x86_64 Suggests: R(data.table) R-SummarizedExperiment-1.10.1-5.fc31.noarch Suggests: R(Biobase) R-SummarizedExperiment-1.10.1-5.fc31.noarch Suggests: R(hgu95av2.db) R-SummarizedExperiment-1.10.1-5.fc31.noarch Suggests: R(AnnotationDbi) R-SummarizedExperiment-1.10.1-5.fc31.noarch Suggests: R(airway) R-SummarizedExperiment-1.10.1-5.fc31.noarch Suggests: R(annotate) R-SummarizedExperiment-1.10.1-5.fc31.noarch Suggests: R(BiocStyle) R-SummarizedExperiment-1.10.1-5.fc31.noarch Suggests: R(GenomicRanges) >= 1.31.17 R-SummarizedExperiment-1.10.1-5.fc31.noarch Suggests: R(IRanges) >= 2.13.16 R-SummarizedExperiment-1.10.1-5.fc31.noarch Suggests: R(HDF5Array) >= 1.7.5 R-SummarizedExperiment-1.10.1-5.fc31.noarch Suggests: R(BiocGenerics) >= 0.15.3 R-SummarizedExperiment-1.10.1-5.fc31.noarch Suggests: R(rhdf5) R-SummarizedExperiment-1.10.1-5.fc31.noarch Suggests: R(TxDb.Hsapiens.UCSC.hg19.knownGene) R-SummarizedExperiment-1.10.1-5.fc31.noarch Suggests: R(GenomicFeatures) R-XVector-0.24.0-2.fc31.i686 Suggests: R(drosophila2probe) R-XVector-0.24.0-2.fc31.i686 Suggests: R(IRanges) >= 2.15.12 R-XVector-0.24.0-2.fc31.i686 Suggests: R(BiocGenerics) >= 0.19.2 R-XVector-0.24.0-2.fc31.i686 Suggests: R(Biostrings) R-XVector-0.24.0-2.fc31.x86_64 Suggests: R(drosophila2probe) R-XVector-0.24.0-2.fc31.x86_64 Suggests: R(IRanges) >= 2.15.12 R-XVector-0.24.0-2.fc31.x86_64 Suggests: R(BiocGenerics) >= 0.19.2 R-XVector-0.24.0-2.fc31.x86_64 Suggests: R(Biostrings) R-ascii-2.1-5.fc31.noarch Suggests: R(weaver) R-biomaRt-2.18.0-12.fc31.noarch Suggests: R(annotate) R-blob-1.1.1-6.fc31.noarch Suggests: R(covr) R-car-2.0.22-5.fc31.noarch Suggests: R(leaps) R-car-2.0.22-5.fc31.noarch Suggests: R(lme4) R-car-2.0.22-5.fc31.noarch Suggests: R(MatrixModels) R-car-2.0.22-5.fc31.noarch Suggests: R(SparseM) R-car-2.0.22-5.fc31.noarch Suggests: R(alr4) R-car-2.0.22-5.fc31.noarch Suggests: R(quantreg) R-car-2.0.22-5.fc31.noarch Suggests: R(pbkrtest) >= 0.3-2 R-car-2.0.22-5.fc31.noarch Suggests: R(rgl) >= 0.93.960 R-car-2.0.22-5.fc31.noarch Suggests: R(survey) R-data.table-1.12.0-2.fc30.x86_64 Suggests: R-xts R-dtplyr-0.0.3-3.fc31.noarch Suggests: R(data.table) >= 1.9.6 R-glue-1.3.1-3.fc31.x86_64 Suggests: R(covr) R-gtable-0.3.0-3.fc31.noarch Suggests: R(covr) R-hexbin-1.27.3-3.fc31.x86_64 Suggests: R(Biobase) R-hexbin-1.27.3-3.fc31.x86_64 Suggests: R(affy) R-knitr-1.25-1.fc32.noarch Suggests: R(sass) R-littler-0.3.8-5.fc32.x86_64 Suggests: R(docopt) R-lmtest-0.9.37-3.fc31.x86_64 Suggests: R(strucchange) R-lmtest-0.9.37-3.fc31.x86_64 Suggests: R(AER) R-lmtest-0.9.37-3.fc31.x86_64 Suggests: R(dynlm) R-memoise-1.1.0-5.fc31.noarch Suggests: R(aws.s3) R-memoise-1.1.0-5.fc31.noarch Suggests: R(covr) R-msm-1.6.6-5.fc31.x86_64 Suggests: R(minqa) R-msm-1.6.6-5.fc31.x86_64 Suggests: R(mstate) R-msm-1.6.6-5.fc31.x86_64 Suggests: R(numDeriv) R-msm-1.6.6-5.fc31.x86_64 Suggests: R(flexsurv) R-multcomp-1.4.10-3.fc31.noarch Suggests: R(ISwR) R-multcomp-1.4.10-3.fc31.noarch Suggests: R(SimComp) R-multcomp-1.4.10-3.fc31.noarch Suggests: R(coxme) >= 2.2-1 R-multcomp-1.4.10-3.fc31.noarch Suggests: R(lme4) >= 0.999375-16 R-multcomp-1.4.10-3.fc31.noarch Suggests: R(tram) >= 0.2-5 R-multcomp-1.4.10-3.fc31.noarch Suggests: R(coin) R-multcomp-1.4.10-3.fc31.noarch Suggests: R(robustbase) R-nanotime-0.2.4-3.fc31.noarch Suggests: R(data.table) R-pkgdown-1.4.1-1.fc32.noarch Suggests: R(covr) R-plyr-1.8.4-12.fc31.x86_64 Suggests: R(covr) R-roxygen2-6.1.1-3.fc31.x86_64 Suggests: R(covr) R-rtracklayer-1.44.0-3.fc31.x86_64 Suggests: R(IRanges) >= 2.13.13 R-rtracklayer-1.44.0-3.fc31.x86_64 Suggests: R(hgu133plus2.db) R-rtracklayer-1.44.0-3.fc31.x86_64 Suggests: R(humanStemCell) R-rtracklayer-1.44.0-3.fc31.x86_64 Suggests: R(BSgenome) >= 1.33.4 R-rtracklayer-1.44.0-3.fc31.x86_64 Suggests: R(microRNA) >= 1.1.1 R-rtracklayer-1.44.0-3.fc31.x86_64 Suggests: R(limma) R-rtracklayer-1.44.0-3.fc31.x86_64 Suggests: R(org.Hs.eg.db) R-rtracklayer-1.44.0-3.fc31.x86_64 Suggests: R(Biostrings) >= 2.47.6 R-rtracklayer-1.44.0-3.fc31.x86_64 Suggests: R(BSgenome.Hsapiens.UCSC.hg19) R-rtracklayer-1.44.0-3.fc31.x86_64 Suggests: R(genefilter) R-rtracklayer-1.44.0-3.fc31.x86_64 Suggests: R(TxDb.Hsapiens.UCSC.hg19.knownGene) R-rtracklayer-1.44.0-3.fc31.x86_64 Suggests: R(BiocGenerics) >= 0.25.1 R-rtracklayer-1.44.0-3.fc31.x86_64 Suggests: R(GenomicRanges) >= 1.31.8 R-rtracklayer-1.44.0-3.fc31.x86_64 Suggests: R(GenomicFeatures) R-snow-0.4.2-8.fc31.noarch Suggests: R(Rmpi) R-stringr-1.4.0-3.fc31.noarch Suggests: R(covr) R-systemfit-1.1.22-5.fc31.noarch Suggests: R(plm) >= 1.0-1 R-systemfit-1.1.22-5.fc31.noarch Suggests: R(sem) >= 2.0-0 R-testthat-2.2.1-1.fc32.x86_64 Suggests: R(covr) R-testthat-2.2.1-1.fc32.x86_64 Suggests: R(devtools) R-viridisLite-0.3.0-5.fc31.noarch Suggests: R(covr) R-waveslim-1.7.5.1-3.fc31.x86_64 Suggests: R(fftw) R-xml2-1.2.2-1.fc32.i686 Suggests: R(covr) R-xml2-1.2.2-1.fc32.x86_64 Suggests: R(covr) R-xtable-1.8.4-2.fc31.noarch Suggests: R(plm) R-zoo-1.8.6-3.fc31.i686 Suggests: R(DAAG) R-zoo-1.8.6-3.fc31.i686 Suggests: R(mondate) R-zoo-1.8.6-3.fc31.i686 Suggests: R(strucchange) R-zoo-1.8.6-3.fc31.i686 Suggests: R(tis) R-zoo-1.8.6-3.fc31.i686 Suggests: R(tseries) R-zoo-1.8.6-3.fc31.i686 Suggests: R(xts) R-zoo-1.8.6-3.fc31.x86_64 Suggests: R(DAAG) R-zoo-1.8.6-3.fc31.x86_64 Suggests: R(mondate) R-zoo-1.8.6-3.fc31.x86_64 Suggests: R(strucchange) R-zoo-1.8.6-3.fc31.x86_64 Suggests: R(tis) R-zoo-1.8.6-3.fc31.x86_64 Suggests: R(tseries) R-zoo-1.8.6-3.fc31.x86_64 Suggests: R(xts)
I've fixed all of my packages, and I've sent out a heads-up to the mailing list that I intend to fix the remaining ones as well (R packages only!).
I see you have these listed in a few places:
Suggests: R(BiocGenerics) Suggests: R(GenomicRanges)
but they exist, so I'm not sure if you have a bug somewhere.
All the remaining packages should be fixed now.
We discussed this at this weeks meeting (https://meetbot-raw.fedoraproject.org/fedora-meeting-1/2019-11-21/fpc.2019-11-21-17.00.txt):
Metadata Update from @james: - Issue untagged with: meeting - Issue tagged with: announce
This was finished a long time ago.
Metadata Update from @qulogic: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.