Re: Bug#924514: multcomp breaks r-cran-dosefinding autopkgtest
On 23 August 2019 at 15:44, Graham Inggs wrote:
| Closing the bug since multcomp has now migrated.
|
|
| On 2019/08/19 21:33, Dirk Eddelbuettel wrote:
| > These problems still seem self-imposed to me. We (maybe randomly ?) appear
| > to be checking (maybe out-of-sync ?) permutations that upstream (ie CRAN)
| > does not see.
|
| Well, not randomly, we check multcomp from unstable against its
| reverse-dependencies from testing.
Sure. But still "random" in the eyes of upstream (as the versions are purely
ours), and orthogonal to their requirements. See below.
| If one of multcomp's reverse-dependencies from testing is not compatible
| with the new multcomp, but there is a new version in unstable that is,
| then it is likely that adding a Breaks to multcomp will hint to the
| package manager not to install them together, thus ensuring we don't try
| to test incompatible versions.
As mentioned, if a new candidate version does not mesh with its reverse
depends in what is current at CRAN, the CRAN admins will not let the new
candidate in. CRAN does all that for the relationships that matter: Depends,
Imports, LinkingTo but not Suggests. That ensures that CRAN almost always
builds and works.
And we can trust this. By keeping our versions fresh and aligned we get
their quality checks for free.
There is nothing wrong with running additional version checks. Just realize
that the corresponding upstream authors may shrug: they work hard to keep the
current version working, not somewhat randomly (to them) chosen arbitrary
ones (as they happen here if a package is behind upstream).
There is a bit more discussion about whether Suggests should be tested like
Depends, Imports and LinkingTo, or not. I tend to argue no, others disagree.
So here, to me it feels odd that we did all this for a _single optional call_
as it was a Suggests: between these two packages.
Dirk
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org
Reply to: