Niko Tyni: > On Fri, Jan 08, 2016 at 12:55:10PM +0200, Niko Tyni wrote: >> Package: perl >> Version: 5.22.1-3 >> Severity: wishlist >> >> Detached debugging symbols are moving to a separate archive suite. >> >> https://lists.debian.org/debian-devel/2015/12/msg00262.html >> >> We should migrate the symbols in perl-debug as well.
Seems reasonable, though please note that you will probably want to keep *non*-debug symbols in perl-debug (e.g. the perl debugger) > > So we can't use "automatic -dbgsym packages" as provided by debhelper, > as we have a long standing tradition of trying to avoid needing perl > (and hence debhelper) to build perl. > I am a bit curious about this. AFAICT several essential packages (now?) use debhelper (incl. coreutils, gzip, tar and dpkg - not to mention glibc). So I do not see how you can get to compile perl without needing perl (before even getting to perl)? Not saying you should use debhelper; I just wanted to challenge the statement a bit to see if it still makes sense. :) > Seems like the easiest way to implement this manually is to put -dbgsym > packages in debian/control just like regular ones. I think you might need to *omit* them from debian/control. > My reading of the > DAK code (at https://ftp-master.debian.org/git/dak.git/) indicates we > just need to name them perl-dbgsym etc., and declare > > Section: debug > Auto-Built-Package: debug-symbols. > > to get them to go in the debug suite (and bypass NEW processing et al.) > > Cc'ing Ansgar, who implemented the DAK side, and Niels, who I understand > designed this whole thing. Is the above correct, or are there other > restrictions? Would we be misusing a private interface between debhelper > and DAK, or are other implementations welcome? > > The "Auto-Built-Package" part makes me a bit uncomfortable, it would be > sort of a lie. Is that a problem? > Assuming you omit the package from debian/control, it would no longer be a lie! :) Thanks, ~Niels
signature.asc
Description: OpenPGP digital signature
