[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 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/
  
> | > 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*?

> | 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
question has some version constraint set upstream and you need a
versioned Build-Depends.  If you can use "any recent R version" it is
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.

Kind regards

       Andreas.

-- 
http://fam-tille.de


Reply to: