what's the purpose of this tool?

  There may exist several versions of an RPM for a single product. novi scans directories for RPMs and finds the latest-version RPM for every product.

  In turn, this data can be used to: - see what are the latest RPMs on your system - fold the latest RPMs into a Kickstart tree, such that you can build systems with the updates already applied

  This process is described in much greater (and better) detail in the following article I wrote for the O'Reilly Network: "Pre-Patched Kickstart Installs"

  `http://www.linuxdevcenter.com/pub/a/linux/2005/02/17/kickstart_updates.html`

what's the origin of the name?

  I wanted a name that would help communicate the tool's purpose: finding new things.

  Speakers of Russian may recognize this word:

  H O B bI
  ("NO-vee")
  "novi" is the Russian word for "new."

  (Yes, given Latin approximations of Cyrillic characters, it should be "novy"; bear with me.)

why did you write this tool?

  To ease my systems management pains.

  I once tried to hand-merge trees of updated RPMs and quickly realized my time would be better spent writing a tool to do the work.

why did you share this tool?

  To ease others' systems management pains.

Isn't that rather bold, releasing this as a 1.0 version?

  Not really. This code has been in incubation for over a year, and it's been running my yum repos just fine. The brief preview release didn't uncover any problems, so I have confidence it will work in others' environments.

what's the license?

  Apache 2.0, except for the STL wrappers around `glob()` -- I released that under a wide-open license when I published it in C/C++ Users Journal (March 2005 issue).

  The license is at the top of every source file.

  The short version is: use novi in any product, commercial or not. Just give credit where credit is due.

Speaking of credit where it's due, did you write novi all by yourself?

  I wrote novi from scratch, but it relies on the RPM API (`librpm`) to extract header information and sort version numbers.

  novi also uses `libpopt` for commandline parsing.

How can novi use an Apache license? Isn't RPM covered by the GPL?

  The RPM tool is covered by GPL, yes; but the RPM developer's toolkit is LGPL. (Refer to the RPM source bundle for details.)

  Therefore, products linked against `librpm` aren't covered by the GPL.

Do you have any examples?

  Yes. Please see the file "EXAMPLES.TXT" in the source distribution.

  Those examples will soon be folded into a proper man page.

The examples show novi being run as a nonroot user. Why is this?

  novi certainly can run as root, but why? The tool was designed such that it could be easily folded into scripts and cron jobs (e.g. right after you've downloaded RPM updates); in turn, it's often safer to let automated processes run as nonroot users. This limits the scope of damage in the event said process goes awry.

From where does novi load RPM data?

  As of version 1.1.0, novi loads RPM data from two source types: directories and repo data files.

  For directories, just specify some path as the source:

      novi ... /some/path

  novi will look for files named `/some/path/*.rpm`.

  Specify the `repo:` prefix to load from a repo data file:

      novi ... repo:/some/path

  novi will try to read RPM header data from `/some/path/repodata/primary.xml.gz`

  All of this is explained in greater detail in the examples.

Why did you add the repo metadata functionality?

  When novi loads data from a directory, it must open every RPM therein to extract header data such as the package name and version. Some collections of RPMs never change (think of the base OS install) so novi wastes a lot of cycles churning through that static data.

  I had considered creating a data store that novi could use between runs -- essentially, a cache of those directories that don't change -- but I realized the Repository Metadata Project had already done it. This project defines a file format to store RPM header info, including that which novi uses. You can run the `createrepo` tool once on such a static repository, and novi can load the data from the resultant metadata file.

  In short, novi users an experience significant performance gains by loading data from a repodata file. You can let `createrepo` do the work and let novi reap the benefits.

I have more questions! Whom can I ask?

  For now, please send messages to

      novi-questions -at- ExMachinaTech -dot- net

  There will soon be a mailing list.