Re: Help making r-cran-rsqlite use Debian's sqlite3 (Was: Re: Bug#657919: ITP: r-cran-digest - Create cryptographic hash digests of R objects)
[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
Reply to: