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
