В Sun, 6 Aug 2023 16:05:03 -0500 Dirk Eddelbuettel <e...@debian.org> пишет:
> One possibility may be to add a new (versioned) field 'Breaks:'. > Matrix could then have added 'Breaks: SeuratObject (<= 4.1.3)' > preventing an installation of Matrix 1.6.0 when SeuratObject 4.1.3 > (or earlier) is present, but permitting an update to Matrix 1.6.0 > alongside a new version, say, 4.1.4 of SeuratObject which could > itself have a versioned Depends: Matrix (>= 1.6.0). I wouldn't entirely agree that Matrix 1.6.0 breaks SeuratObject 4.1.3, given that it's still possible to install first Matrix 1.6.0 and then SeuratObject 4.1.3. The breakage definitely exists, but not on the source package level. It may also not be easy for the package developer to notice breaking a binary package while performing reverse dependency checks, in time to add such a notice to their package. The recommended way to do that is tools::check_packages_in_dir(), which works on source packages. Would it help to reframe the problem in terms of binary packages acquiring dependency constraints that are more strict than those of the corresponding source packages? If a package that imports S4 classes from another package and thus ends up caching their definitions, R could compute a hash of the classes being imported, store it together with the installed package and complain noisily if the hash doesn't match later at load time. This could be used to detect such problems automatically (but could also result in false positives!). This is not the only way a binary package could accidentally depend on internals of another binary package. I remember reading about (but cannot find it now!) some packages "importing" a function from ggplot2 (I think) by assigning it into their namespace: foo <- ggplot2::useful_function This worked for quite a while, but later broke because ggplot2::useful_function called an internal function which ceased to exist in a new version of ggplot2. This is arguably a bug and probably even harder to track, but are there any other ways to catch a "binary dependency" for a package? -- Best regards, Ivan ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel