Dirk Eddelbuettel: > > On 20 December 2015 at 21:52, Niels Thykier wrote: > | Dirk Eddelbuettel: > | > > | > Hi Niels, > | > > | > Thanks for the prompt and detailed answer! It addressed all my questions. > | > > | > On 20 December 2015 at 21:11, Niels Thykier wrote: > | > | Dirk Eddelbuettel: > | > | > I was just updating one of my several dozen r-cran-* packages. These > all use > | > | > the same (source) r-cran.mk script shipped with the main R packages. > | > | > > | > | > And now all of sudden it wants to build a -dbgsym package. > | > | > > | > | > That may not be such a good idea for the several hundred r-cran-* > packages. > | > | > I have been looking around the Deverloper Reference and Wiki (plus > Google > | > | > searches) but not found a way to suppress this. What am I missing? > | > [...] > | > | Please have a look at [1]. Though if your reason for disabling them > are: > | > | > | > | * Upload speed / personal bandwidth costs. > | > | - Then please consider using "source-only" (or arch:all+source) > | > | uploads, which is unaffected and keeps the dbgsym. > | > | > | > | * That they take up a lot of mirror space etc. > | > | - Then please keep in mind that they are off-loaded to a separate > | > | mirror network and therefore will not burden users / developers > | > | except those who explicitly enable them. > | > | > | > | * If you have other concerns with them, please let me know. :) > | > | > | > | At the same time, the dbgsym packages can be used to assist debugging > | > | your packages or retracing coredumps. They will also be available from > | > | snapshot.debian.org, so you can retrace coredumps from previous uploads > | > | as long as they had a dbgsym package. > | > > | > Thanks a bunch. The link below did fix it. I had just setup a test > | > environment in Docker and the env.var will do. > | > > | > I think will patch the 'debian/rules snippet' we ship with r-base-core to > | > instruct dh_strip to not create these for now. _Right now_ we end up with > | > Lintian errrors hence my first gut instinct to suppress this. > | > | What error is that (and what version of lintian)? > > E: r-cran-hmisc-dbgsym: extended-description-is-empty > W: r-cran-hmisc-dbgsym: wrong-section-according-to-package-name > r-cran-hmisc-dbgsym => gnu-r > W: r-cran-hmisc-dbgsym: debug-package-should-be-named-dbg > usr/lib/debug/.build-id/ >
And what version of lintian is this? If you are using lintian from unstable or stable-backports, you shouldn't be seeing these warnings. > | > The -dbg > | > packages are a good idea; I provide them as eg r-base-core-dbg and for the > | > GSL etc. These may make sense for R packages too, but the r-cran.mk > snippet > | > needs some work to postprocess what dh_gencontrol et al create. > Volunteers? > | > > | > Dirk > | > > | > [...] > | > | Why do you need any postprocessing of the dh_gencontrol output? The > | output of dh_gencontrol for dbgsym packages are synchronized with what > | dak expects (and requires) of them. > | Or are you considering to extend the dbgsym packages with R specific > | debug information? That on the other than should be doable, but it > | would have to happen before the call to dh_gencontrol. > > My analysis may have been premature. This may all be addressable when > creating a new debian/control entry. If so shouldn't the build abort when > there is no new debian/control entry? > > Dirk > I am sorry, I am not sure what you are asking. Perhaps you could tell me in details what you are hoping to achieve? Thanks, ~Niels
signature.asc
Description: OpenPGP digital signature
