About the usage of Build-Depends in R packages (Was: Your upload of r-cran-xts)
- To: debian-r@lists.debian.org
- Cc: Debian Developers <debian-devel@lists.debian.org>
- Subject: About the usage of Build-Depends in R packages (Was: Your upload of r-cran-xts)
- From: Andreas Tille <andreas@an3as.eu>
- Date: Fri, 16 Mar 2018 08:26:48 +0100
- Message-id: <[🔎] 20180316072648.ocwm7zrhxzbzp5kd@an3as.eu>
- In-reply-to: <23210.63656.66268.568978@rob.eddelbuettel.com>
- References: <20180315074148.6fztuerqulczaqjx@villemot.name> <23210.22606.659889.156042@rob.eddelbuettel.com> <20180315135333.vdojrnnrzwiznitv@an3as.eu> <23210.63656.66268.568978@rob.eddelbuettel.com>
[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: