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
I wanted a name that would help communicate the tool's purpose: finding new things.
Speakers of Russian may recognize this word:
(Yes, given Latin approximations of Cyrillic characters, it should be "novy"; bear with me.)
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.
To ease others' systems management pains.
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.
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.
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.
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.
Yes. Please see the file "EXAMPLES.TXT" in the source distribution.
Those examples will soon be folded into a proper man page.
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.
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/pathnovi will look for files named
/some/path/*.rpm
.
Specify the repo:
prefix to load from a repo data
file:
novi ... repo:/some/pathnovi 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.
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.
For now, please send messages to
novi-questions -at- ExMachinaTech -dot- netThere will soon be a mailing list.