Re: r-cran-polycub 0.5-0-1
[Moved private discussion to the list with permission of the author]
On Fri, Jul 04, 2014 at 10:29:51PM +0200, Sebastian Meyer wrote:
> Hello again,
>
> > Please note that I'll take the
> > freedom to quote you in public if there is no private content in your
> > mail to simply inform other members of the team as well.
> Yes of course!
>
> Just to clarify my use case: I'm not using the debian
> packaging of R or CRAN packages at all. Since I'm developing R
> packages, I compile R myself (with special options) and like to control
> package updates myself (usually I want to be up-to-date with all
> important packages but sometimes I decide to postpone an update until a
> research project is finished etc).
I guess postponing upgrades is an important requirement in science.
Independently we had some discussion in Debian how to approach this.
There are some means (like pinning a package or fetching a certain
package version from snapshot.debian.org. But there is no ultimate
solution to this problem.
> However, I appreciate your work since it supports the spread of R
> packages in the debian/linux community. I was wondering how many are
> actually using the debian repository to install R packages. Do you have
> any idea?
We have some rough estimation about the minimum number of users who are
really actively using a package by the popularity-contest mechanism.
Hint to all readers: If you would like to enhance our estimation please
make sure you have set "Yes" when you do
sudo dpkg-reconfigure popularity-contest
So if (and only if) at the Debian machine in question has popcon
configured to report the package usage we get the numbers. For instance
in case of r-cran-surveillance the numbers can be seen here
http://blends.debian.org/med/tasks/epi#r-cran-surveillance
which means that 22 people are using (== really using the package since
its files are touched) and 12 people upgraded it recently. Specifically
for such specialised packages I'd consider this a high number -
especially if you keep in mind that the package is currently in contrib
and not automatically installed by the Debian Med metapackages (which
will change with the soon to expect upgrade of r-cran-surveillance 1.8.0
which is in the new queue). You might like to scroll upwards to see the
popcon numbers of other R packages.
> I assume that it is a lot of work to keep all those packages up-to-date
> with upstream, also if you only do "balanced upgrades".
Yes, we can not manage to upgrade all R packages right in time which has
lead to some criticism ([A],[B]). I like the term "balanced upgrades"
which pretty clearly describes what I'm approaching.
> One new package
> triggers a bunch of dependencies and so forth, as you said.
> On the contrary, it is so easy to install.packages() and
> update.packages() from within R, or even use the CRAN task view system
> with the "ctv" package to straightforwardly install a whole bunch of
> packages related to a specific domain. More regular R users will have to
> install.packages() anyway since not all packages are also packaged for
> debian (or they are not recent enough, which was the case for
> surveillance with a 4 year old version). So who does actually use the
> packages provided through debian?
The idea for packaging r-cran-surveillance (and other R packages in the
field of epidemiology) has a different view on the problem. We try to
provide a helping hand to the epidemiologist who is wondering: What
free software could I use in my field of work. The answer is provided
by the simple command:
apt-get install med-epi
It is "by chance" that a lot of packages in epidemiology are R packages
(which is not that prominent in other fields). To get an overview over
all packages in some field it is not always the main point of every
package out of a larger set is in sync with the last upstream version.
> Maybe mostly those who are using R
> only irregularly or who would like to give it a try. These people don't
> get the most recent versions of R packages and they have to wait for the
> debian maintainer to upgrade not knowing when this will happen. But
> maybe that's not an issue for such users.
I'm honestly hoping that those users who might have a problem with not
up to date software will raise this issue. Currently the situation with
R packages is quite good since I have done a major overhaul in June. I
try to get this done also before Debian will freeze for the next stable
release. There are also a lot of scientific users who use a stable
system intentionally and do not even mind about the difference to
upstream but stick to what is delivered in Debian stable (or Ubuntu
LTS etc.)
> The one advantage of Debian packaging of R is for packages (and R
> itself) that have external dependencies, i.e., require some system
> library to be installed. This is where integrated package management
> simplifies installation.
+1
> > My recent work also involved adding
> > tests whereever possible so we will notice automatically if something
> > might went wrong.
> Yes why not. This seems to be helpful for balanced upgrades. If Debian
> would be in sync with CRAN, then CRAN itself assures running packages
> with its regular checking.
While I personally do not know all the testing mechanisms I'm not really
sure whether the testing on CRAN runs in all dimensions Debian is
testing. For instance Debian is running tests on different hardware
architectures which might uncover problems with different endiannesses,
floating point implementations etc.
> > Once this cycle is over I only will answer explicite requests and in
> > October another rush of updates will happen to become up to date at
> > the time of Debian freeze in begin of November.
> I wonder who would take the effort to send a request to Debian if he/she
> could just do install.packages to get the latest version?
I hope these 22 users of the package will do. Your question was also
raised in the bug report[A]. From our (== the Debian Med team)
perspective we deal with all types of packages in the same way. While R
packages have the mechanism you are mentioning other packages do not
have this. We simply try to support epidemiologists, biologists and
other people working in medicine and biology with all relevant packages.
There is no specific focus or handling of R packages. We simply hope
for "grown up" users to talk to us about their requirements to find the
optimal solution for them.
> Best regards and thanks again for your contributions,
Thanks for your time to share your insight
Andreas.
[A] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617296#66
[B] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752609#15
> On 25.06.2014 09:35, Andreas Tille wrote:
> > Hi Sebastian,
> >
> > switching to English since this might enable us moving the discussion to
> > the mailing list where it belongs to. Please note that I'll take the
> > freedom to quote you in public if there is no private content in your
> > mail to simply inform other members of the team as well.
> >
> > On Tue, Jun 24, 2014 at 11:41:37PM +0200, Sebastian Meyer wrote:
> >> On 24.06.2014 16:59, Andreas Tille wrote:
> >>> Ist im SVN schon geändert, denn ich arbeite bereits an der neuen
> >>> Version.
> >>
> >> Wow, das ist schnell!
> >
> > Well, it came into a "general update of all R packages of Debian Med".
> > In any case I always try to be quick if I get a notice either by mail
> > (preferably to the mailing list) or via a bug report "new version
> > available". My personal limit for a reaction is 48h (except I'm on
> > vacation). Just to let you know that there are other opinions of well
> > respected R packagers in Debian[1] and I would be interested what you
> > might think about my opinion expressed later in this page that
> > interested users could claim their interest on new versions explicitly.
> >
> > If i would be a valid request to always hunt behind the latest upstream
> > version of an R package the only alternative I would see otherwise is to
> > drop these R packages at all since we have other packages besides R in
> > the Debian Med team and try to do what I would call ballanced upgrades.
> > For me this means I dedicate a certain time spann (since I started it
> > took me about 2.5 weeks since I started this cycle) to push all packages
> > to a consistent up to date state. My recent work also involved adding
> > tests whereever possible so we will notice automatically if something
> > might went wrong. The hard part are always new Dependencies either for
> > building or testing so it takes some time.
> >
> > Once this cycle is over I only will answer explicite requests and in
> > October another rush of updates will happen to become up to date at
> > the time of Debian freeze in begin of November.
> >
> > What do you think about this plan as somebody who is obviously concerned
> > about the update of a specific R package.
> >
> >>> Der Upload wird aber noch eine Weile dauern, weil:
> >>>
> >>> - Ich will r-cran-maptools durch weglassen von non-free Daten
> >>> in main reinbringen und die non-free Daten in ein separates
> >>> Paket auslagern. Dann könnte nämlich auch r-cran-surveillance
> >>> in main.
> >>
> >> maptools ist eines der Pakete das nicht mehr notwendig ist um mit dem
> >> surveillance Paket arbeiten zu können. Es wird im manual einige Male
> >> referenziert und in einigen Code-Beispielen und Funktionen verwendet
> >> (falls verfügbar). Es ist aber nicht erforderlich für die Pakettests.
> >
> > That's very good news that r-cran-manual is not needed any more. I'm
> > tempted to push r-cran-surveillance to unstable even if we can not yet
> > fullfill all preconditions for testing since it is good to move from
> > contrib to main which will also require some manual check by ftpmaster
> > that might last some time. Once this is done may be all dependencies
> > for the test are available and we could upload a package with testing
> > included.
> >
> >> Ich sehe jetzt glaube ich die Schwierigkeit eine "Depends"-Liste für
> >> r-cran-surveillance zu erstellen. Ich dachte erst, man könnte
> >> grundsätzlich einfach die Pakete aus den "Depends" und "Imports" Feldern
> >> der DESCRIPTION übernehmen. Allerdings ist das nicht unbedingt
> >> ausreichend um auch alle Tests laufen lassen zu können, was du ja
> >> anstrebst. Dafür braucht es noch Pakete aus "Suggests".
> >
> > Yes, the tests need some components from Suggests. I will add these
> > packages as Recommends in debian/control and they also need to be
> > specified as Depends in debian/tests/control.
> >
> >>> Welche genau wären denn das?
> >>
> >> Für die Tests in surveillance 1.8-0 werden die beiden folgenden Pakete
> >> aus "Suggests" benötigt: maxLik, spdep
> >
> > I injected r-cran-maxlik[3] and r-cran-spdep[4] for exactly this purpose
> > some hour before your mail arrived. ;-) Unfortunately both of these
> > packages need some also not yet available packages to build and these
> > are now in SVN and also in the Debian NEW queue[5]. Once these two
> > packages are accepted by ftpmaster I can push maxlik and spdep to the
> > new queue. This new processing is slowing down the upgrade process to
> > some extend and I have no influence on its progress.
> >
> >> Die Pakete aus "Depends" und "Imports" sind natürlich sowieso
> >> Abhängigkeiten für r-cran-surveillance:
> >>> Depends: R (>= 2.15.2), methods, grDevices, graphics, stats, utils,
> >>> Rcpp, sp (>= 1.0-15), xtable, polyCub (>= 0.4-2)
> >>> Imports: MASS, Matrix, spatstat (>= 1.36-0)
> >>
> >> Im Vergleich zur aktuellen Liste in der control-Datei sind also folgende
> >> Pakete hinfällig: spc, maptools, vcd, msm, colorspace
> >> Die Minimum-Version von spatstat wird mit 1.36-0 angegeben, in der
> >> control-Datei wird dagegen 1.37-0 gefordert?
> >
> > While this is technically equivalent since there is no spatstat 1.36-0
> > Debian package (I just gave reasons why we are not packaging each
> > upstream version above) I changed this in SVN as well[1].
> >
> >> Ich bin nicht sicher ob es bzgl. der r-cran-* Abhängigkeiten überhaupt
> >> einen Unterschied zwischen Build-Depends und Depends geben sollte?
> >
> > You are true that for R packages Build-Depends and Depends are usually
> > equal. I really considered writing some tool which automatically adds
> > the Build-Depends to the Depends fields but on one hand I was not sure
> > whether this might be correct in each and every case even if I had no
> > counter example in mind. On the other hand I just filed bug #752609[6]
> > which would consequently lead to a situation which has more
> > Build-Depends than Depends are needed. In case you would add the unit
> > test to the build process (which I'm in favour of very strongly) you
> > need to add all packages which are needed for the tests as
> > Build-Depends. These are not necessarily Depends for running the
> > package and should rather settle as Recommends (or Suggests) in the
> > debian/control file.
> >
> > So while I do agree for the moment to your remark I hope that this will
> > be not true in the future once #752609 might be fixed.
> >
> > Kind regards and many thanks for your helpful comments
> >
> > Andreas.
> >
> > [1] http://anonscm.debian.org/viewvc/debian-med/trunk/packages/R/r-cran-surveillance/trunk/debian/control?view=diff&r1=17288&r2=17291&diff_format=h
> > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617296#66
> > [3] http://anonscm.debian.org/viewvc/debian-science/packages/R/r-cran-maxlik/trunk/debian/
> > [4] http://anonscm.debian.org/viewvc/debian-science/packages/R/r-cran-spdep/trunk/debian/
> > [5] https://ftp-master.debian.org/new/r-cran-learnbayes_2.15-1.html
> > https://ftp-master.debian.org/new/r-cran-misctools_0.6-16-1.html
> > [6] https://bugs.debian.org/752609
--
http://fam-tille.de
Reply to: