Bug#841076: perl: running enc2xs -C on (de-)installation of Encode::* packages

[Niko Tyni]

On Mon, Oct 17, 2016 at 03:19:52PM +0200, Florian Schlichting wrote:
> Package: perl
> Version: 5.24.1~rc3-3
> Severity: wishlist

> I was looking at #758847, which asks to run 'enc2xs -C' after
> installation of Encode::* packages so that Encode is informed about all
> encodings that are currently installed. (This has previously been
> mentioned in bugs such as #304433, even though that was really a
> different problem.)
> 
> This seems to be a sensible request IMHO, but would need to be done for
> all libencode-*-perl packages as well as perl itself, and thus should be
> thought through a little bit before implementation.
> 
> 'enc2xs -C' is implemented in make_configlocal_pm(); it searches @INC
> for installed Encode::* modules and then writes out the result as
> /usr/lib/x86_64-linux-gnu/perl/5.24/Encode/ConfigLocal.pm using
> /usr/share/perl/5.24/Encode/ConfigLocal_PM.e2x as template, basically
> creating a long list of 'require Encode::...' statements.
> 
> Processing is rather fast, so this wouldn't necessarily need a dpkg trigger
> but could be run from postinst / postrm. On the other hand I wonder how
> Encode reacts if one of the modules is removed and Encode is called
> _before_ 'enc2xs -C' has been run again?
> 
> Niko mentioned on IRC that the ConfigLocal.pm should probably go in /var
> and be symlinked into @INC.
> 
> Encode itself doesn't seem to run 'enc2xs -C' during installation, nor
> does it mention it in its README. Is ConfigLocal.pm only meant for
> home-made encodings?

Thanks for raising this. The feature indeed seems useful even though it's
somewhat underdocumented and underused upstream. Some thoughts:

- from a Debian POV, it would be cleanest if the packages providing extra
  encodings could just ship separate files in a ConfigLocal.d/ directory
  or something, and ConfigLocal.pm would read those in. This would mean
  that no code needs to run at installation time

- OTOH, the specifics of how to make an encoding available to Encode
  (%Encode::ExtModule and arguably even enc2xs) are in the domain of
  Encode itself, not the other packages. This makes a dpkg trigger
  solution feel the "right" answer to me: the extra encoding packages
  can then use a declarative syntax and not care about the details
  (they don't even need to know about enc2xs)

- a file trigger on /usr/lib/<triplet>/perl5/5.24/Encode/ (possibly
  generalized to all of @INC except '.') might make it possible to
  implement this without any changes to the extra encoding packages.
  I'm not sure if there are some gotchas here but it may be worth a try

- it would indeed be bad if Encode was broken all the time from the
  installation/removal of an extra encoding package until a deferred
  trigger gets run. I doubt that's the case but it's certainly something
  that needs to be checked if a trigger solution is chosen

- ConfigLocal.pm should indeed go in /var IMO if we start handling it even
  semi-automatically; enc2xs currently puts it wherever Encode.pm is
  but that should be easy to patch

- there are two Encode.pm providers (perl and libencode-perl); care
  needs to be taken to handle that right (although I note that
  libencode-perl doesn't currently ship enc2xs at all)

- enc2xs loads in all the Encode::* modules; in the case of a trigger
  based implementation, we should make sure that the perl package doesn't
  fail its configure stage even if there's a garbage Encode::Whatever
  module in /usr/local (i.e. 'postinst triggered' fails gracefully)

Sorry that I'm making this so complicated. Possibly we should just stick
in 'enc2xs -C' in a handful of libencode-* postinst + postrm scripts
and be done with it (though the /var thing at least is necessary to
avoid an FHS violation, I think.)
-- 
Niko