Re: [ftpmaster@ftp-master.debian.org: dh-r_20160916_amd64.changes ACCEPTED into unstable, unstable]
Hi Gordon,
On Thu, Oct 27, 2016 at 03:44:35PM +0200, Gordon Ball wrote:
> >>
> >> Quite a few are probably now out of date (bioconductor release in the
> >> meanwhile), but yes, I can push some updates once I'm able to verify the
> >> builds without needing to inject a local copy of dh-r.
> >
> > Just to let you know: I'm working down the packages from BioConductor
> > right now and I do the dh-r conversion on my own - so there is no point
> > for you to do anything in SVN.
>
> Apologies - real life intervened and I didn't get round to pushing my
> version, which are now mostly superceded, as you say. I'll look through
> the d-science packages I also tested, but some manual work is needed
> since the original modifications were automated without eg, commit or
> changelog messages, so I won't likely do so before the weekend.
I'm now through (most of) the BioConductor packages. The conversion
turned out to be very simple - so please simply forget my request to
push anything. I can copy with the transition.
> > BTW, I noticed that
> >
> > export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow
> >
> > has no influence and the lintian warning about missing bindnow remains.
>
> This came up during the previous dh-r thread. R controls the build
> environment and I wasn't able to find a workable way of injecting
> LDFLAGS. See the message from Dirk at [1].
>
> (Some workarounds can be found on google for CFLAGS and CPPFLAGS but
> they appeared not to work for LDFLAGS, or at least, I couldn't get them
> to work).
>
> [1]: https://lists.debian.org/debian-science/2016/09/msg00029.html
Hmmm, I was hoping that this would be some side effect of the
conversion. May be ist should be reported to R upstream to enable
tweaking LDFLAGS?
> I hope using the package has been otherwise unproblematic?
Yes, besides #842092 I observed one issue I'd like to propose. I have
injected
Recommends: ${R:Recommends}
Suggests: ${R:Suggests}
in all the converted packages. However, it seems the R:Recommends
variable is not really used. My strategy to put packages into
Recommends was: "If a package is needed to run the unit tests it makes
sense to add the packages to Recommends so a user who uses a default
installation which includes Recommends can immediately test the
package."
Do you think this makes sense? I guess it would be easy to parse
debian/tests/control for such candidates for Recommends.
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: