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

About the usage of Build-Depends in R packages (Was: Your upload of r-cran-xts)



[For readers on debian-devel the part of the discussion about
 Build-Depends started here
   https://lists.debian.org/debian-r/2018/03/msg00052.html]

Hi Dirk,

On Thu, Mar 15, 2018 at 05:50:16PM -0500, Dirk Eddelbuettel wrote:
> 
> On 15 March 2018 at 14:53, Andreas Tille wrote:
> | Can you please give a technical reason for the versioned Build-Depends?

Thanks for the verbose answer explaining your motivation to add
versioned Build-Depends which are not needed to simply build r-cran-*
packages.
 
> a) R does not like it if you don't do it.
> 
>    If you build under R a.b.d with d > c and then run with R a.b.c (where,
>    again, c < d) you get a silly warning.  I don't want those, the constraint
>    helps enforce it.

I do not think that your means is really helpful.  Lets stick to the
example of r-cran-xts which you uploaded with r-base-dev (>= 3.4.3).  At
the time of uploading the constraint was fullfilled in unstable anyway
so had no real effect.  If you upload r-base-dev (>= 3.4.4) today
r-cran-xts remains build against r-base-dev (== 3.4.3) and will remain
until any new upload of r-cran-xts.  So you get the silly warning
starting from today on.

The manual constraint you have explicit put on does not change this
situation.
 
> b) It doesn't really matter.
> 
>    I do put current R into unstable (ie today, with the release of R 3.4.4.

If it does not really matter why are you spending your time on it?

> c) It doesn't matter for your backports either.
> 
>    The substitution via sed or perl is trivial.

  * Its some extra step a backporter needs to do
  * The backporter is always wondering whether droping the constraint is
    correct or not since as a backporter you will never know whether there
    is a technical reason or not.  For all other packages I backported
    this usually means I need to backport the according version of
    the Build-Dependency.

>  Keeping track of
>    Build-Depends is harder.

I do not think so.  IMHO you are not keeping track but you just put in
artificial versioned dependencies to r-base version that is *by chance*
the current one for no visible effect (see a) ).
 
> Besides, I do it for my packages, as I happen to like it that way.
> 
> I don't run around admonishing to do, or not do it so it really should not be
> of any concern to you.

I explained why it is a concern in c).
 
> I have yet to meet a _single user_ who was affected one way or the other.

Build-Depencencies rarely affect users since these are not exposed to
the resulting binary package.  Its affecting developers, most probably
not only backporters but also porters to other architectures.  I could
assume that some architectures are lagging behind r-base and thus will
not be able to build packages with unneeded Build-Depends.  IMHO, this
is simply misuse of Build-Depends.

> The person complaining is ... you, and last I checked you didn't claim you
> were that deeply into R.  So can we move on?

This fact exactly meets te point I made in my second item of c):  Since
I'm way less involved in R than you I always need to do some research
whether the Build-Depends is really needed or not.  I would be happy if
we would not move on but if Build-Depends would be used if needed and
otherwise be droped.  The advantage for you would be that you can save
time for yourself.

Kind regards

       Andreas. 

-- 
http://fam-tille.de


Reply to: