Bug#810327: perl: move to dbgsym packages

[Niko Tyni]

On Fri, Apr 15, 2016 at 06:26:21AM +0000, Niels Thykier wrote:
> 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)

Somewhat confusingly, the perl debugger (= perl5db.pl) is in
perl-modules-*. The thing in the perl-debug package is /usr/bin/debugperl,
a perl binary compiled with -DDEBUGGING to enable assertions and the
like. I was thinking that one would stay in perl-debug, yes.

> > 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. :)

Yeah, it's a good question that I was sort of avoiding :) It has come
up every now and then, I think the last time was with #797106 (binNMU
changelogs). So far we've sticked to tradition. See also

 http://lists.alioth.debian.org/pipermail/perl-maintainers/2012-January/002870.html

The point is obviously architecture bootstrapping. The idea is/was
roughly that you can build a static perl binary, temporarily install
it into /usr/bin/ and then go ahead building the package. Any reverse
dependencies on perl would need to be at least force-installed or
something. Of course you'd need a compiler and libc and coreutils and
so forth, I suppose either cross compiled or non-packaged at this point.

Now, I haven't really ever tried this myself, and it may well have
bitrotted. Clearly bootstrappers are managing somehow, though, and
we should really ask them if this is helpful anymore.

I note that the recent progress on perl cross build support has promise
in this area and might well let us stop worrying about all this. However,
it's new enough that I wouldn't really want to count on it quite yet.
 
> > 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.

The options I see are either to go the dh_gencontrol way and create
DEBIAN/control files for the -dbgsym packages on the fly, or hardcode
them in the source debian/control file. The latter feels simpler to me.
The most useful thing about the automatic creation part AFAICS is not
having to change all the Debian source packages, which is not relevant
for this case.

I don't see why having -dbgsym packages in debian/control couldn't work,
unless there are some restrictions about them not listed in some part
of the .changes file (maybe Binary:) or something like that?
-- 
Niko