Item13046: missing local perl path in debian packages

pencil
Priority: Low
Current State: Needs Developer
Released In: n/a
Target Release: n/a
Applies To: Extension
Component: DebianPackage
Branches:
Reported By: GuilainCabannes
Waiting For:
Last Change By: SvenDowideit
When intalling System.filterplugin by the debian package, the package libtext-unidecode-perl (which containt text::unidecode) is not automatically installed. This cause an crash when you use FilterPlugin.

-- GuilainCabannes - 05 Oct 2014

Seems to be the FilterPlugin DEPENDENCIES file, and not the debian package itself. The file is empty. Probably needs to be:

Exporter,>=0,cpan,May be required for lib/CPAN/lib/Text/Unidecode.pm
Foswiki::Func,>=0,cpan,Required
Foswiki::Plugins,>=0,cpan,Required
Foswiki::Render::Anchors,>=0,cpan,Required
POSIX,>=0,cpan,Required
Text::Unidecode, >=0,cpan,Required
utf8,>=0,cpan,May be required for lib/CPAN/lib/Text/Unidecode.pm

Hm... And BuildContrib missed Text::Unidecode from the generated file.

-- GeorgeClark - 06 Oct 2014

This is a DebianPackage and not a FilterPlugin problem as it ships Text::Unidecode as part of the ZIP. I am not sure why a debian-based install would omit those from @INC.

As such above DEPENDENCIES file should not be required.

-- MichaelDaum - 06 Oct 2014

On two debian install, the /var/lib/foswiki/lib/CPAN/lib is absent of the INC path

Feature or error ?

-- GuilainCabannes - 06 Oct 2014

I think that this is a feature. Thou shalt not install cpan modules when a deb pkg exists for the module. libtext-unidecode-perl is the "Debian" way. Otherwise you miss out on security updates, bugfixes, etc. provided by the Debian maintainers.

-- GeorgeClark - 06 Oct 2014

Link to Item12191

-- GuilainCabannes - 06 Oct 2014

The automatic DebianPackage builder tries its best to derive debian dependencies from the list of things listed in DEPENDENCIES. However in a couple of cases this does not work out correctly. Best would be to craft a debian/ sub-directory manually, write down the proper Debian dependencies there and check it into git.

Whether to use a matching system package or not really is a case-to-case decision considering:

  • dependencies on rather esoteric perl packages
  • packages are broken and/or unmaintained upstream and need local patching for Foswiki needs
  • packages simply aren't available in regular Linux distributions

When building a Debian package decisions might be resolved one or the other way. In any case /var/lib/foswiki/lib/CPAN/lib MUST be included in @INC to leave the path open for extensions to come with a local version of a CPAN package. That's standard in Foswiki and TWiki for ages.

Perl is facing a very difficult situation in most enterprise Linux distributions: old and long-known broken perl packages that won't be updated on these distros any time soon via their system-level packages. Constructing modern perl applications on such an outdated base won't be possible, even less for web applications.

The only way out is installing a local perl, either completely using tools such as plenv or perlbrew ... or in parts us /var/lib/foswiki/lib/CPAN/lib.

That's why it is so important to have it in @INC as a last resort.

-- MichaelDaum - 07 Oct 2014

Regardless, I think any CPAN packages should be listed in DEPENDENCIES, even if they are shipped with the package. Foswiki 1.2 includes a DependencyReport that covers core + all installed extensions. This is quite useful for debugging of failures (what version of blah is installed), etc.

Dependencies don't get reported if they are omitted. I'd much rather err on the side of a bit too much information regarding dependencies than too little.

-- GeorgeClark - 08 Oct 2014

But there is no external dependency for FilterPlugin. Why would I list them in DEPENDENCIES? FilterPlugin does ship Text::Unidecode for the sole purpose to prevent any exotic extra package to be installed in addition ... given it was available on the target platform.

-- MichaelDaum - 09 Oct 2014

But that's the point, shipping Text::Unidecode in the lib/CPAN/lib directory does not make Foswiki use it. lib/CPAN/lib is at the end of the path, the "last resort". (unless the side modifies LocalLib.cfg So if some other package, unrelated to foswiki, happens to install Text::Unidecode, that exotic extra version is the one that Foswiki will use. And that information will be hidden from DependencyReport.

If you want to ship a version of Text::Unidecode that is locally modified, it might be a good idea to rename it to FilterPlugin::Text::Unidecode or something. Otherwise you've really got no control over which version is in use, and you've hidden the diagnostic messages that would reveal the version in use.

-- GeorgeClark - 10 Oct 2014

Sorry but there really is no problem here other than the debian builds by Sven not offering the standard way of a last resort because lib/CPAN/lib is not included in @INC for no obvious reason.

Besides that Foswiki extensions have very well control whether their own or the system-wide version of a CPAN package should be used by shipping it in:

  • lib/CPAN/lib: function as a last resort ... ERROR: currently not possible on a debian install
  • lib/: function as a locally modified version that takes higher precedence over system libs

In both cases no entry is required in DEPENDENCIES.

-- MichaelDaum - 10 Oct 2014
 

ItemTemplate edit

Summary missing local perl path in debian packages
ReportedBy GuilainCabannes
Codebase 1.1.9
SVN Range
AppliesTo Extension
Component DebianPackage
Priority Low
CurrentState Needs Developer
WaitingFor
Checkins
TargetRelease n/a
ReleasedIn n/a
CheckinsOnBranches
trunkCheckins
masterCheckins
ItemBranchCheckins
Release01x01Checkins
Topic revision: r12 - 11 Oct 2015, SvenDowideit
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy