jmod request

Tom Marble tmarble at info9.net
Tue Apr 27 07:16:57 PDT 2010


On Tue, Apr 27, 2010 at 6:12 AM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> Mark - is uninstall feasible? I assume there is potential for consistency
> issues if there is library delegation and a module is removed from a parent
> library. Also, I wonder about the consequences of uninstalling a module when
> the library is in use by a running application.

It seems that jmod wants to be able to handle install and uninstall
(gracefully).
We really don't want to repeat the problem like the Windows Registry which
simply gets corrupted over time and results in the need to regularly
reinstall the OS.

We may be able to get some inspiration from how Debian manages
package installation (and removal) with apt-get [0].  Specifically there are
commands which:

  'remove' will remove a package (and and any packages which
  depend on it), but some configuration information
  will remain for the package (e.g. files in /etc/ ).

  The is a 'purge' command which will remove everything
  for a package (including configuration files).

  There is a '--force-yes' option (highly discouraged) to cause
  the operation (e.g. 'remove') to continue despite violating
  package interdependencies -- this would be equivalent to the
  'rm -r module-directory' approach.

  normally 'install' will refuse to reinstall a package if it is
  already at the same version of the proposed new package.
  However, one can specify '--reinstall' to reinstall even if
  the package is at the newest version.

Note that there are various front ends to Apt which can prompt the
user to interactively resolve dependency problems or automate
installation, etc. [1]  The flow of operations is described here [2] which
leverages install hook scripts [3].

Debian (and UNIX systems generally) have the facility to
upgrade running programs [4].  This speaks to the need for a convention
for start/stop scripts (*a la* Sys V [5]) for Java programs (daemons).
 This is likely
beyond the scope of Jigsaw itself, but does suggest how hooks in Jigsaw
could allow Java programs to gracefully handle lifecycle management with
the native packaging system.  Removing packages for running programs
may not cause them to abort as their binaries and libraries may trivially
be in the filesystem cache, but clearly expectations about polite behavior
in such circumstances should be modest.  We don't need to assume
that a Jigsaw administrator would have higher expectations.

Regards,

--Tom

[0] apt-get man page (slightly out of date, purge is now a command
    not a --purge qualifier)
    http://linux.die.net/man/8/apt-get
[1] Apt front ends (e.g. that allow interactively resolving dependency problems)
    http://wiki.debian.org/Apt
[2] Apt event flow
    http://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_the_event_flow_of_the_package_management
[3] {post|pre}{inst|rm} files
    http://www.debian.org/doc/manuals/maint-guide/ch-dother.en.html#s-maintscripts
[4] Update running program
    http://www.debian.org/doc/FAQ/ch-pkgtools.en.html#s-updaterunning
[5] start/stop scripts
   http://en.wikipedia.org/wiki/Init



More information about the jigsaw-dev mailing list