[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
 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
> | > 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

> 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

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


[1] http://lists.debian.org/debian-med/2012/02/msg00023.html 


Reply to: