This question about Developing extensions (plugins skins etc.): Answered

include in MANIFESTs

I am finishing a script to process the distributed files in an installed wiki; parsing MANIFESTs seems the way to go. (The script handles permissions policies, including SeLinux stuff, so the MANIFEST provides the list of files & standard permissions - and other stuff - more on that later in another topic. I promised to release this a while ago, and it will probably turn into a feature proposal. For now, trust that I'm doing something sensible and need to understand how MANIFESTs are supposed to work.)

I'm confused by includes.

trunk/core/lib/MANIFEST contains includes, e.g.
!include ../EditTablePlugin/lib/Foswiki/Plugins/EditTablePlugin

but under svn EditTablePlugin isn't in core/, it's in trunk. E.g.
trunk/EditTablePlugin/lib/Foswiki/Plugins/EditTablePlugin/MANIFEST exists in an svn checkout, and

<pre>lib/Foswiki/Plugins/EditTablePlugin/MANIFEST is actually installed.</pre> doesn't have the ../ syntax, but does mention the package name before lib/...

(TWiki looks the same, and yes, I'm still dealing with it, too)

So what is the ../ supposed to be relative to? Is this an artifact of the build process, or something significant in real life?

Is it safe to just strip ../<word>/ and assume that all includes are relative to the installation root?

Or maybe I should simply do a File::Find::find on MANIFEST in the entire installation tree, and ignore include alltogether?

I'd rather not could someone authoritiative explain what's really going on?


-- TimotheLitt - 22 Jul 2011

Unfortunately we don't ship a complete Manifest file with Foswiki. The "include" statements reference the individual MANIFEST files in each extension, however they don't get packaged/shipped with Foswiki. If you are working with a SVN checkout, then those files will be found. The ../ is relative to the "core" directory, as the extension source is relative to one level up from core. The build is run from the core directory, so everything is relative from there, not the lib directory containing the MANIFEST file.

See Tasks.Item8898 and some other related Manifest issues / enhancements are listed under Tasks.BuildContrib

-- GeorgeClark - 22 Jul 2011

Uggh. I was afraid of that. Shipping a file with relative references to a directory that isn't shipped isn't very social...

Real story at Development.SecurityChecklists. Perhaps that will encourage work on the other issues...


-- TimotheLitt - 23 Jul 2011

QuestionForm edit

Subject Developing extensions (plugins skins etc.)
Extension BuildContrib
Status Answered
Related Topics
Topic revision: r3 - 23 Jul 2011, TimotheLitt - This page was cached on 12 May 2020 - 16:51.

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