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)
On 8 February 2012 at 15:45, Andreas Tille wrote:
| On Wed, Feb 08, 2012 at 08:26:13AM -0600, Dirk Eddelbuettel wrote:
| >
| > | > I am a little swamped with a few other things but
| > | >
| > | > a) a complete patch
| > |
| > | I could do this probably.
| >
| > Good.
| >
| > | > b) a debian/control file using
| > |
| > | All control files which are currently used by Debian Med should be
| > | working examples.
| >
| > I have none here so I'd still appreciate one...
|
| Just picking a random one:
|
| apt-get source r-cran-epi
|
| 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.
| > | > would help. We actually need $(R_Version) twice in Builds-Depends and
| > | > Depends. This can address both uses, right?
| > |
| > | Build-Depends is technical impossible and does not even make sense.
| >
| > Huh? It's still just textual substitution.
|
| 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.
| > | Those Variables can simply not be used in Build-Depends because they are
| > | just calculated in the build process. It's the same with all substvars
| >
| > But I agree that it happens 'too late', after the build.
|
| Yes.
|
| > | used by debhelper - you will never find those in Build-Depends. It's
| > | the other way around: You always build against the version in unstable
| > | and this version defines what will be considered as version the binary
| > | package will depend on.
| >
| > 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*. 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).
You may have too narrow a Debian focus here.
| 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.
| 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.
Dirk
| Kind regards
|
| Andreas.
|
| --
| http://fam-tille.de
--
"Outside of a dog, a book is a man's best friend. Inside of a dog, it is too
dark to read." -- Groucho Marx
Reply to: