Re: Can I suppress automatic creation of -dbgsym packages?
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/
| > 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
--
http://dirk.eddelbuettel.com | @eddelbuettel | edd@debian.org
Reply to: