[Moving a non-Debian Med related issue to debian-devel. (reply-to set) The relevant part of this thread starts at http://lists.debian.org/debian-med/2012/02/msg00074.html and might be interesting for people building R packages. ]
On Wed, Feb 08, 2012 at 09:37:12AM -0600, Dirk Eddelbuettel wrote: > | Other examples can be viewed here: > | > | http://anonscm.debian.org/viewvc/debian-med/trunk/packages/R/ > > I asked you to email it. It's ten lines. Sorry, I missed the "email" part - can perfectly do so in case we agree about the requested patch makes sense or not. > | But a textual substitution by *what*? > > Value of the most current R, which I am always running on the system I > prepare the debian/* files.... > > A helper script could even have a _constant_ value (or in a dot.rc file) > which we update every six months. Sorry, I do not get your point in how far this should help reducing the effort. > | > Then I am /much/ less interested in the patch as it doesn't really help > with > | > the workflow for the maintainer. We're going from a manual edit of two > | > fields on a file to one. Still leaves us needing to open/edit the file. > | > | Why? I do not need to edit the control file of r-cran-epi (and others) > | any more. Your statement is true if (and only if) the package in > > Then you are doing it wrong. As soon as a new R forces changes, you *need to > build with those*. I'm actually doing this by building in a recent unstable chroot: $ sudo cowbuilder --update $ pdebuild How can you tell this the wrong approach? That's default that you build against the R version recently available in unstable. > See eg the recent changes to the help system. Also, when > CRAN packages interdepend you often need the newest version, Build-Depends on > the newest R gets you that (albeit indirectly). There is no need to Build-Depend from the newest R if it is determined by the way you build the package. The best you gain when fixing the Build-Depends to a certain version is that backporters will have to touch the packaging. If you are not fixing the Build-Depends version and rather make the Depends according to the version the package was builded against, you can safely build it even as backport / other distributions. > You may have too narrow a Debian focus here. Sorry, I can not parse this. Please explain. > | question has some version constraint set upstream and you need a > | versioned Build-Depends. If you can use "any recent R version" it is > > It's not. Sometimes we need a specific miminum version that may not have been > built on all arches etc pp. So far as I understand this actual "sometimes" is determined by upstream requirements as I wrote or am I missing something? > | fine to go with a non-versioned Build-Depends (and we are doing so in > | the majority if not all Debian Med packages). The ${R:Depends} just > | records which actual version of r-base-dev was used in the build > | process and you are done. > | > | > A tool to more easily set the Build-Depends would be of use. > | > | *If* you need to adjust a versioned Build-Depends of an R package > | because upstream needs a specific version, you need to edit something > | anyway - so why not doing it at the usual place. I admit I do not > | really understand your feature request. > > Yes, we are wasting each other's time. Let's keep things the way they are; > you guys add your snippet if you feel you need it. > > What we have works reliably for over a hundred packages. No need for changes. On the contrary there are about 50 packages using a method you are calling builded the wrong way. If you are right I would see a need for changes. You initially said we found a "Nice substvars trick."[1] I volunteered to provide a patch to make it avialable for all R packages (BTW, when not using ${R:depends} in your debian/control nothing happens at all - so it is totally non-invasive to your packaging). When discussing this more detailed you claim that we are doing things wrong. I know that in Debian Science this method is used as well (that's why I'm asking for the wider audience to make them aware of a more general problem). So if we are really doing things wrong I would love to read a better explanation I'm able to understand to fix things (also bug reports are welcome). Kind regards Andreas. [1] http://lists.debian.org/debian-med/2012/02/msg00023.html -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120208162735.gq9...@an3as.eu
