In general terms, a package is a unit of software that serves a single +OpenACS sites.
In general, a package is a unit of software that serves a single well-defined purpose. The OpenACS Package Manager (APM) provides a mechanism for packaging, installing, and configuring OpenACS software in a consistent, user-friendly, and subsite-aware manner.
The OpenACS Package Manager (APM) consists of:
A standard format for APM packages including:
Version numbering, independent of any other package and the OpenACS as a whole
Specification of the package interface
Specification of dependencies on other packages (if any)
Attribution (who wrote it) and ownership (who maintains it)
Web-based tools for package management:
Obtaining packages from a remote distribution point
Installing packages, if and only if:
All prerequisite packages are installed
No conflicts will be created by the installation
Configuring packages (obsoleting the monolithic OpenACS configuration file)
Upgrading packages, without clobbering local modifications
Uninstalling unwanted packages
A registry of installed packages, database-backed and -integrated with file system-based version control +integrated with filesystem-based version control
Web-based tools for package development:
Creating new packages locally
Releasing new versions of locally-created packages
Uploading packages to a global package repository on the web
Use of these tools should be safe, i.e. installing or removing a package @@ -126,7 +126,7 @@ returned by the system API.
Provisions will be made to assure that packages are securely identified.
4.600.1 Each package will have a PGP signature and there -will be MD5 time stamps for each file within the package. +will be MD5 timestamps for each file within the package.
4.600.5 The APM will provide a facility to validate both @@ -147,22 +147,22 @@ information for unique fields specified in the data model requirements, the package cannot be created.
20.0 Add files to a package
20.1 The developer must be able to add files to the package. This is done by copying the files into the package directory in the -host OS's file system. Files can be added at any point after package +host OS's filesystem. Files can be added at any point after package creation.
20.3 Once a package has been versioned and distributed, no new files should be added to the package without incrementing the version number.
20.5 The APM's UI should facilitate the process of -adding new files, by scanning the file system for new files automatically, +adding new files, by scanning the filesystem for new files automatically, and allowing the developer to confirm adding them.
20.10 The developer cannot add files to a given package -via the UI that do not exist in the file system already.
20.15 Package file structure must follow a specified +via the UI that do not exist in the filesystem already.
20.15 Package file structure must follow a specified convention. Please see the design document for what we do currently.
30.0 Remove files from a package
The developer must be able to remove files from a package. This can be done in two ways.
30.1 Access the APM UI, browse the file list, and remove files.
30.1.1If a file is removed from the package list, but not -from the file system, an error should be generated at package load time.
30.5 Remove the file from file system.
30.5.1 The APM UI should take note of the fact that the +from the filesystem, an error should be generated at package load time.
30.5 Remove the file from filesystem.
30.5.1 The APM UI should take note of the fact that the file is gone and offer the developer an option to confirm the file's deletion.
40.0 Modify files in a package.
40.1 The developer should be able to modify files in the -file system. The APM UI should not interfere with this.
40.5 However, if the developer modifies files containing +filesystem. The APM UI should not interfere with this.
40.5 However, if the developer modifies files containing procedural definitions, APM UI should allow a means to watch those files and automatically reload them if changed. See requirement 50.0 for more detail.
40.10 Also, although a change in files implies that the @@ -178,8 +178,7 @@
60.0 Display an XML package specification
60.1 The developer should be able to view the XML package specification that encodes all package information. -
70.0 Write an XML package specification to the file -system
70.1 The developer should be able to write an up-to-date +
70.0 Write an XML package specification to the filesystem
70.1 The developer should be able to write an up-to-date XML specification to disk.
70.5 The developer should be able to request the current XML specification for all installed, locally generated packages.
130.0 Distribution file generation
130.1 The developer should be able to generate a .APM distribution file for the package with just one click.
130.5 Generating a distribution file implies doing an @@ -246,7 +245,7 @@ is enabled.
110.0 Package Deinstall
110.1 The administrator must be able to deinstall a package that has already been installed. Deinstallation entails:
110.1.1 Running any data model scripts necessary to drop the package.
110.1.5 Moving all of the files into a separate location -in the file system from the installed packages.
4.110.1.10 If the package is a compound package, then +in the filesystem from the installed packages.
4.110.1.10 If the package is a compound package, then the administrator must confirm removing all sub-packages. Optionally, some sub-packages can be kept.
110.5 Deinstalled packages can be re-installed at a later date.
4.110.10 If deinstalling a package or any of its @@ -256,9 +255,7 @@ package, all related database tables and content.
120.5 This option can only be used if all package instances are deleted or marked as disabled. This is purposefully cumbersome because deleting all instances of a package can have far-sweeping -consequences throughout a site and should almost never be done.
150.0 Scan for new or modified packages
150.1 The administrator should be able to scan the file -system for any changes made in any of the installed package files.
150.5 The administrator should be able to scan the file -system for any newly installed packages. +consequences throughout a site and should almost never be done.
150.0 Scan for new or modified packages
150.1 The administrator should be able to scan the filesystem for any changes made in any of the installed package files.
150.5 The administrator should be able to scan the filesystem for any newly installed packages.