Bug#810823: perl: break .ph files into a separate (source?) package

[Niko Tyni]

On Tue, Jan 12, 2016 at 05:40:25PM +0200, Niko Tyni wrote:
> Package: perl
> Version: 5.22.1-4
> Severity: wishlist

> I propose that we break these .ph files out into a separate
> perl-system-headers binary package. I would also like to separate their
> generation into a separate source package, which could use something
> like our current build time checks as its test suite, as there's no real
> reason to tie them to src:perl anymore. The source package could use h2ph
> from perl or bundle/fork its own; I'm not sure which would be cleaner.

Thinking this through aloud:

- we want to ship /usr/bin/h2ph with perl as long as upstream does,
  even if we don't ship the generated .ph headers
- wherever they are, the .ph headers should probably be generated with
  /usr/bin/h2ph rather than a separate copy
- the hypothetical src:perl-system-headers would therefore need to
  Build-Depend on perl (I'm ruling out a separate binary package for
  just h2ph, which is clearly overkill)
- bin:perl-system-headers would need to put the generated headers
  into an arch-specific directory on @INC, presumably $Config{vendorarch}
- bin:perl-system-headers would therefore need to Depend on perlapi-*
- if bin:perl Depends:perl-system-headers and bin:perl-system-headers
  Depends:perlapi-*, a separate src:perl-system-headers would cause a
  build dependency loop in the transitive Build-Essential set, which
  would be a problem for perl transitions (old bin:perl-system-headers
  would be uninstallable with new perl-base, but src:perl-system-headers
  would need new bin:perl to get rebuilt)

Conclusion: we can't make a separate src:perl-system-headers package
as long as bin:perl Depends on bin:perl-system-headers, which is
probably until stretch is released.

That's fine, it just means we need two steps to this: separating the
binary package before stretch and the source package after stretch.

Pre-stretch, we could just make perl Provide:perl-system-headers and
migrate the reverse dependencies, then separate both the source and binary
package out after stretch, and have perl Recommend perl-system-headers
until stretch+1. OTOH, making perl-system-headers a real binary package
straight away would get the transition done sooner.

Both approaches probably suffer from aggressive autoremoving by aptitude,
as depicted #808430. Not sure if there's anything we can do about that
except document things.

(Sorry about the longish dump about such a minor thing. Hope it
makes at least a bit of sense :)
-- 
Niko Tyni   ntyni at debian.org