Feature Proposal: Add the ability to add a "remove" status for files in the manifest

Motivation

Currently to remove stale files, it has to be done either manually, or by a pre/post install exit. There have been some extension changes that required files to be removed to ensure correct operation.

Description and Documentation

Add a !remove option to the MANIFEST file

• Any files following the !remove would have a (remove) option set in the generated _installer manifest.
• Extension installation would include files marked for removal in the backup.
• Files would be removed during manifest processing.

The 1.1 installer includes an improved backup mechanism which should make this relatively low risk and a needed improvement.

Examples

MANIFEST:

lib/Foswiki/Plugins/TinyMCEPlugin.pm 0644
!noci
pub/System/TinyMCEPlugin/anchor.gif 0644
!remove
pub/System/TinyMCEPlugin/Obsolete.gif 644

Impact

Changes required to BuildContrib, as well as Foswiki::Configure::Package, possibly Foswiki::Configure::Util

Extensions generated with !remove would probably encounter difficulties if installed on 1.0.x - Use of the feature should be restricted to Extensions released for 1.1 and beyond.

(A minor change to 1.1 Package.pm - to ignore (remove) items in the manifest would simplify migration to include this feature).

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: GeorgeClark - 29 Mar 2010

Discussion

There are two days before feature freeze.

And this proposal will get nowhere near having a discussion and conclusion before. We require 14-days to make a decision.

And on the top of it, adding a feature that deletes files and creates a compatibility issue is high risk.

We need to think carefully and long before we add a feature that deletes anything.

And the idea that there are extensions that are 1.1 is incorrect. The ideal is that extensions are compatible also with older releases.

There are exceptions, but they should be exceptions. I am not ever going to agree on a feature that is not implemented so 1.0.X will be able to use it. An extension to the MANIFEST syntax which is not understood by 1.0.X is wrong. It is not necessary to implement such a feature in a way that will make 1.0.9 fail. The list of deleted files can be added to another file that 1.0.9 ignores.

I am raising concern right away. If this feature goes through, it will be for 2.0.0 scope. Time is out for 1.1. And this is not a killer feature for 1.1.0 that we cannot live without. If extensions being upgraded leave behind a few files too many, it is normally not a problem at all. It is a nice to have feature. It can wait for 2.0

-- KennethLavrsen - 30 Mar 2010

Unfortunately I wasn't clear above in my description. I had no intention to add this for 1.1.

As far as extensions leaving behind files - the reason this came up was exactly because some left behind sites broke things and it was reported on the list.

My 1.1 comment was not intended to implement any of the feature. It was to have the Manifest code in Package.pm ignore any lines flagged for (remove) so that when/if we add the feature for 2.0, 1.1 would be more tolerant. It would NOT be a 1.1 feature.

-- GeorgeClark - 30 Mar 2010

I'm changing this to rejected. The accepted Feature UseEnhanceAndMoveSpecFiles can cover this requirement by allowing comparison of the installed Manifest vs. the new Manifest. There should be no reason to flag files as requiring removal in the manifest.

-- GeorgeClark - 05 Dec 2010