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

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.

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