Q1. What is GNUpdate?
Q2. How does it work?
Q3. How will dependencies work?
Q4. What type of database will be used?
Q5. Will GNUpdate support clusters?
Q6. Does GNUpdate use a proprietary package format?
Q7. Why not just use (apt-get, ports, etc.)?

See the About GNUpdate page.

GNUpdate has different back-end libraries for handling the various tasks. These core libraries are libgnurdf, libcomprex, libpackman, and libpql.

Front-end tools (such as gnupdate and gpkg) interface with these libraries to access packages and package databases.

When one of the front-end tools requests information on a package, libpackman locates the package module for the package and uses the module to query for the requested information. The package modules are also used for extracting files from packages, installing packages, and uninstalling packages.

Database modules are handled the same way, but through libpackman's database modules. Most GNUpdate installations will contain at least two database modules: one for GNUpdate itself, and one for the installed Linux distribution's native package database.

Cross-package dependencies are all standardized within libpackman. The package's native dependencies will automatically be translated to libpackman's internal dependencies on-the-fly. This should allow different types of packages to be installed without conflicting with each other.

A document on dependencies, including pseudo-code describing how they are translated, will be available soon.

At the moment, the GNUpdate database is a collection of gzipped RDF files. Since RDF is an XML format, it should be easy to read to and write from any RDF capable program. Though it's not recommended to modify the database yourself, it can be done if necessary. RDF is slow, however, so the database is now being rewritten. It was useful for debugging early on, but now that GNUpdate is reaching the point of usability, a better solution is needed.

The new database format is based off B+Trees. Multi-user access is being kept in mind while this is designed. It does not depend on any external libraries. The code is currently libpackman's CVS tree. If you use libpackman right now, it will be built by default. It is not yet usable, however, so unless you want to help develop the new database, you'd be best off sticking with an older version of libpackman.

The GNUpdate database was designed to be a remote database as well as a local database. The online GNUpdate Package Database is simply a GNUpdate database on the web, filled with package entries. This design allows for multiple package entries to be installed, providing users the option of choosing which version or branch of which package they want.

A more advanced front-end will be used for making changes to the GNUpdate database when the project is further along.

There are methods that can be used to support clusters.

As stated in "What is the database like?," the GNUpdate database has the capability to be used remotely. The computers in a cluster can query a central computer's package database (which must have gnups installed) for new packages, and then install them. The clients would only need to put an entry for gpkg in a crontab on each system, and they will stay current with the latest packages.

The actual packages themselves can either stay remotely on the Internet or on the server running gnups. By default, when installing a package, an entry is made in the database specifying where the package was retrieved. A feature will be added in gnups to translate local paths to ftp or http urls.

No. It is designed to use existing package formats. However, it does provide a new package definition format in RDF. These are fully optional, and do not replace any existing package formats.

This package definition format contains general information about the package itself. This is used when retrieving information about a particular package from the remote GNUpdate package databases.

It can also be bundled within a project's source code directory or tarball to allow GNUpdate easier access to the information about the package. If this is not found, GNUpdate will attempt to use other methods to find this information (such as scanning RPM .spec files, debian directories, etc.).

This is a common question I have been asked. There is a misconception that GNUpdate is simply an auto-update system, similar to apt-get or ports or whatever. As described in About GNUpdate, GNUpdate provides a universal interface to various package formats and databases. It can act as an auto-updater, but also allows installation of "foreign" packages.

Perhaps more importantly, it provides a single front-end for packages, so that if you move from one Linux distribution to another, you won't have to re-learn the package management system. You can continue to use GNUpdate.