Hydra Conceptually

Hydra should be a fusion between a 'ports-like' system for building and packaging software from source code and a frontend that is the specialized tool for binary package management, (including packages built with the Hydra backend), That is, The backend of Hydra is a specialized tool for compiling source into an installable .pkg.7z package that comply with the SVR4 packaging standard. The original SVR4 front end tools (pkgadd, pkgrm ..) have been rewritten in Ada as a backward compatible front end to the advanced XML based package meta data storage in Hydra's back end.

What is a ports-like system?

'Ports' is a system used by *BSD, which allows source packages to be downloaded, unpacked, patched, compiled and installed. A 'port' is merely a small directory on the user's computer, named after the corresponding software to be installed, which contains a few files with instructions for downloading and installing an application from source, typically by navigating to the directory, or port, and doing 'make' and 'make install'. The system will then download, compile and install the desired software.

Hydra's Backend

Hydra is made up of a directory tree, (the Hydra Tree), residing under /var/hydra, which contains many subdirectories, each within a category, and each named by their respective, buildable package. This tree represents (but does not contain) all of the supported AuroraUX software components, retrievable is done through hg version control system. You may refer to each package-named subdirectory as an 'AURA' with the prefix of AURA*, much the way one would refer to a 'port'. These AURA, or subdirectories, do not contain the software package, nor the source, but rather, contain a PKGBUILD file, (and sometimes other files). A PKGBUILD is a simple build script- a text file containing the compilation and packaging instructions as well as the URL of the appropriate source LZMA compressed tarball to be downloaded. (The most important component of Hydra backend are its PKGBUILD files.) By issuing the hydra buildSVR4 command, the software is first compiled, and then packaged within the build directory before being installed. Now you use of the Hydra frontend is invoked to install, upgrade, and remove your new package.

Hydra Backend Overview

'Hydra' may be used as an umbrella term, since it includes and relies on several other components. Therefore, though not technically accurate, 'Hydra' can refer to the following structure and tools as a complete toolkit:

The AURA tree: The AURA directory structure under /var/hydra/ on your (local) machine. It contains many subdirectories, named for all available software from repositories specified in /etc/hydra.conf, but not the packages themselves.
AURA: A set of tools to retrieve and build PKGBUILDs. Example PKGBUILDs are also included.
PKGBUILDs: Text build script files residing under the hydra directories, or that are custom made, with instructions for building packages and the URL of the sources.
buildSVR4: Shell command tool which reads the PKGBUILDs, automatically downloads and compiles the sources and creates a .pkg.7z (SVR4 package).
Hydra frontend: The Hydra frontend is completely separate, when invoked it installs or removes the built package, as well as for fetching dependencies.
StarDust: User/ISV and Blastwave/AuroraUX Projects.The AuroraUX Community Repository is separate from AuroraUX itself, however Hydra although unsupported can use PKGBUILDs to built by use of the hydra buildSVR4 tool, to compile and package up software.

Why a ports based backend to Hydra?

The Hydra backend build system is used to

Recompile a package
Make and install new packages from source, of software for which no packages are yet available.
Customize existing packages to fit your needs (enabling or disabling options, patching).
Rebuild and cross compile the entire AuroraUX distribution using our standard compiler flags for PPC, SPARC and x86. - Much like NetBSD.
Easily compile and install a newer, older, beta, or development version of a particular package by editing the version number in the PKGBUILD.

Misc

TODO List

Finish PKGBUILD spec file parser. - In progress..
Implement pkgSVR4, which takes the parsed output of a PKGBUILD file and builds a SVR4 package by doing the following;

generate a 'pkginfo' file. - In progress..
run the build script. - In progress..
generate a prototype file (which list all the useful files generated by the buildscript).
use pkgmake & pkgtrans (which takes the prototype file as input) and builds a solaris package installable by 'pkgadd'

Build a PHP frontend to also parse PKGBUILD files in the hg repso and print (useful info) about them.
Implement the network transport layer of Hydra using the PolyOrb Ada runtime. - In progress..
Implement Hydra's internal metadata storage by means of Ada/XML.
Implement the pkgmk, pkgtrans, pkgadd, etc.. commands in Ada as part of the Hydra software suit.
Write specs on how the BeleniX distro constructor works and write this in Ada to become part of Hydra's native command set.. - In progress..

Idea List

AURA* are *system* packages, That is:

Core packages should not obey the same rules, they go to predefined directories the "distribution" and 3.rd party software should be separated.

Use a list on the package repository to check for system vulnerabilities:

Example: ftp://ftp.netbsd.org/pub/pkgsrc/distfiles/vulnerabilities

Distributed network transport layer by use of the PolyOrb Ada runtime. - On TODO list.
PKGBUILD spec file parser. - On TODO list.
SVR4 package constructor. - On TODO list.
ISV packages must *not* pollute the system.
Allow building of boot environments using ZFS tech.
Allow rolling back in case of broken upgrade using the boot environment feature.
Hydra Configuration file (/etc/hydra.conf) defines:

Mirrors.
NFS shares.
hg src repo.
etc..

System constructing and cross compiling by use of Hydra + fresh check in of AuroraUX src from hg repository.
GRUB menu configuration file parser and menu constructor. - Need to search for other OS's and auto create a menu item for each, also parser menu.lst file on any mountable FS found.
Automate deployment of applications and security patches across the network.