wpkg --deconfigure

Submitted by Alexis Wilke on Sat, 12/15/2012 - 01:04
Options Comments
--admindir Define the administration directory, where the database of the installed packages resides.
--debug Define a set of flags of things to print out for debug purposes.
--dry-run Run all validations then exit.
--force-all Ignore all problems that can be bypassed.
--force-depends Accept installing packages with missing dependencies.
--force-hold Remove package even if marked as being on hold.
--force-remove-essential Allow wpkg to delete essential packages
--instdir Define the installation directory, where the data files are installed on the target.
--no-act Run all validations then exit.
--no-force-all Prevent any --force-... command line option from being used.
--no-force-depends Prevent packages with missing dependencies from being installed.
--no-force-hold Prevent packages that are on hold from being removed.
--no-force-remove-essential Prevent the removal of essential packages, this is the default.
--quiet Request for minimal output. For the --verify function this is the default behavior.
--recursive Recursively scan the --repository directories or remove all dependencies automatically.
--refuse-all Prevent all problems from ever being bypassed.
--refuse-depends Prevent packages with missing dependencies from being installed.
--refuse-hold Prevent packages that are on hold from being removed.
--refuse-remove-essential Prevent the removal of essential packages, this is the default.
--root Define the installation root path.
--simulate Run all validations then exit.
--tracking-journal Specify the filename of the journal where commands that can be used to rollback the system are saved.
--verbose Display log information of level INFO.

 

The --deconfigure command is used to deconfigure a package that was previously installed with the --install command (or unpacked and later configured, etc.)

A validation process similar to the --remove command validation process is run before the deconfiguration takes place. If the package is depended on by installed packages then the deconfiguration cannot happen.

Note that only currently configured packages can be deconfigured with this command. For this reason, the command only accept names of installed packages.

The --deconfigure command runs the pre-removal script (prerm) with the keyword deconfigure. If the script fails, wpkg runs the postinst script with the abort-deconfigure command:

prerm deconfigure
if failed then
    postinst abort-deconfigure
end if

Note that if the postinst also fails, then the package is now in an unstable state: Half-Configured. If the abort succeeds, then the state is returned to Installed and the package does not get deconfigured.

When the prerm deconfigure script runs with success, the deconfigure command further renames all the configuration files as <conf-filename>.wpkg-user so that way they do not get used by the package. If a file named <conf-filename>.wpkg-user already exists, it is silently replaced by the current <conf-filename>. The <conf-filename>.wpkg-user files are restored on a later --configure or --install of that package.

IMPLEMENTATION NOTE

This is NOT what dpkg does. First of all, dpkg does not offer a --deconfigure command line option, but on top of that they do not rename installed configuration files on --unpack (they use the --unpack command to deconfigure a package.)

Also we consider a deconfiguration to be similar to a removal process whereas dpkg using --unpack views it as an installation process.

Note further that we do support the dpkg behavior with our own --unpack command. Only the --unpack forces the unpacking of all the files found in the package which is a lot more work than just deconfiguring as this --deconfigure command does.

Another way to deconfigure a package is to use the --unpack command. There are two drawbacks to using the --unpack: (1) it re-extracts all the files which may not be what you want to happen; and (2) the configuration files found in the package are extracted and saved as <conf-filename>.wpkg-new. These two side effects drove us to have a separate --deconfigure command.

IMPORTANT NOTE

If you are programming a server, it is very important to ensure that it gets stopped by the prerm script and that it doesn't get started again (immediatly, or on a reboot, or any command that is generally used to start such a server.) The package content will still be available and therefore the executable can still be run! You do not have, however, to prevent the user from starting your executables if one does so explicitly.

For more details about the installation process see the --install command, specifically, the Configuring chapter.