I'm not sure I like that idea, because then we are propagating packages that do not build and/or check (even though there's a big fat warning when you load them).
Also I don't like the idea of modifying the build system so close to the release, and I don't have a lot of time to do that. We could look into doing it after the release if it's decided to do this. Dan ----- Original Message ----- > From: "Hervé Pagès" <hpa...@fredhutch.org> > To: "Dan Tenenbaum" <dtene...@fredhutch.org> > Cc: "bioc-devel" <bioc-devel@r-project.org> > Sent: Monday, October 5, 2015 4:57:38 PM > Subject: Re: zzz.R in GenoView > > Hi Dan, > > What about modifying the build system to propagate deprecated > packages > that install? That also means that the build system should also be > modified to always perform the INSTALL step for a deprecated package. > > H. > > On 10/05/2015 03:31 PM, Dan Tenenbaum wrote: > > Yes, this is part of a larger problem we need to think about. > > > > I marked several packages as deprecated. In each case, the package > > has not built successfully (and propagated) in some time. So the > > deprecation message will not propagate to the end user, and the > > special landing page text will not be present (if the web site > > code sees "PackageStatus: Deprecated" in a DESCRIPTION file it > > will add some special text to the landing page, saying the package > > is deprecated, with further instructions, but again that only > > shows up if the package builds succesfully). > > > > Most of the time when we mark a package as deprecated we are doing > > it because it does not build (and we can't reach the maintainer). > > So there is this paradox that the deprecation warning we insert > > will rarely be seen by end users. > > > > This seems to be at odds with the intent of what we are trying to > > do. > > > > So instead what will happen when the end user tries to install one > > of these packages (now or after the release) is: > > > > - if the package did not build at all during the release cycle (or > > if we flushed our > > internal repos, a normal step leading up to release), biocLite() > > won't find it > > - if it did build during the release cycle, the last good build > > will be installed, and will > > not show the deprecation warning > > > > Maybe this is all ok. In the rare case where a package still builds > > but we decide to mark it as deprecated for another reason, the > > warning will be seen as intended. > > > > FYI > > Dan > > > > PS. Hervé, I fixed the Collate field for GenoView. > > > > ----- Original Message ----- > >> From: "Hervé Pagès" <hpa...@fredhutch.org> > >> To: "Dan Tenenbaum" <dtene...@fredhutch.org> > >> Sent: Monday, October 5, 2015 3:21:27 PM > >> Subject: zzz.R in GenoView > >> > >> FYI > >> > >> > >> http://bioconductor.org/checkResults/3.2/bioc-LATEST/GenoView/linux1.bioconductor.org-buildsrc.html > >> > >> Looks like zzz.R needs to be added to the Collate field. > >> > >> That will still not make the new version propagate though (because > >> its > >> vignette is broken, I think) so something else would need to be > >> done > >> if > >> we want the Deprecation message to reach the end user and/or the > >> package > >> landing page. > >> > >> H. > >> > > -- > Hervé Pagès > > Program in Computational Biology > Division of Public Health Sciences > Fred Hutchinson Cancer Research Center > 1100 Fairview Ave. N, M1-B514 > P.O. Box 19024 > Seattle, WA 98109-1024 > > E-mail: hpa...@fredhutch.org > Phone: (206) 667-5791 > Fax: (206) 667-1319 > _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel