If you want to read the source, then you probably want to know what is meant with certain words or classes. I hope the following doesn't make it worse :-)
A specrepository is some source of spec files, for example the subversion of rpmforge or the CVS of PLD or some directory with a bunch of spec files. You have to configure each SpecRepository in the configuration file /etc/pydar2/specrepositories.conf (part of pydar2-master). You have to add a section for each SpecRepository to this file, for example:
[rpmforge] type=SVN fulldir=/var/lib/pydar2/specrepos/rpmforge/rpmsThe name of the section is the name of the SpecRepository. The type should be one of SVN, CVS or FILES. This type is needed so pydar2 knows how to generate a versionid of a certain file and how to generate an update command for a specrepository. The fulldir contains the absolute directory to the checkout of your spec files. Normally this is a subdirectory of /var/lib/pydar2/specrepos.
A SpecRepositorySpecFile is the class which represents one spec file within a SpecRepository.
These are different implementations of the superclass SpecRepository. They contain specific implementations for the versionid of a spec file and for generating the update command for a SpecRepository.
This class can create SpecRepository objects.
This object contains the list of SpecRepository objects in the master server. It is accessible from Config.
A distroarch is a combination of a distribution with an architecture. For example: Red Hat Enterprise Linux 4 for i386, which can be written as rhes4-i386. Most of the time, the short notation is used like fc1-i386 or au1.92-sparc like in yam. This list is currently not changable unless you know a bit how to use a postgresql database. The distroarchs are stored in the table pydar2_distroarch. They have a unique distroarchtag like 'rh9-i386', a name like 'Red Hat 9 i386', and a field 'defines' which looks like ' --define "rh9 1"'. You can view the current list with the query 'select * from pydar2_distroarch'.
This one wasn't a very good choice i guess.. This is not the same as a %buildroot in a spec file. The Buildroot class is a class which is able to build rpms for a certain distribution/architecture. The Buildroot class itself doesn't do much: it's a superclass which defines certain functions and other classes like YumBasedBuildroot implement those functions.
This class contains the list of buildroots of a slave buildmachine. It's accessible from the Config object.
A BuildRootResult object contains some information and logging about the build of one spec file. The BuildRoot object creates a BuildRootResult object when it processes a Command. For example it contains the output of rpmbuild and the names of the resulting rpms and srpm.
CallableScript is a wrapper around a userdefined function. You need a modulepath and a name of a function and it provides a function _getMethod() so you can call this function easily.
A Command object represents one command given by a client, created and queued by a master and executed by a slave. It contains fields like:
A MasterCommand represents a command within the master. It is able to fetch data in the postgresql database for example. You can create a CommandValueObject from a MasterCommand object.
A SlaveCommand represents a command within the slave. It doesn't fetches any data itself. It is created with a CommandValueObject which contains already all the data.
This class can only contain some values and is used for transferring a MasterCommand to a SlaveCommand by xmlrpc.
This class should represent the list of commands in the master, but for the moment it only stores new commands.
Pydar2 works in a distributed way and used xmlrpc to talk between the nodes. There's always only one master which holds the queue and doesn't build any rpms itself.
A slave-buildserver does the actual building. It asks the master for commands. It has a list of distarchs for which it is able to build rpms.
The Config class contains all the configuration variables of a master, slave or client. It reads configuration files if needed. It can also contain a CommandList, TargetList and SpecRepositoryList object if it is used within the master. It can also contain a BuildRootList if it used within a slave.
A Filter object is a wrapper around a userdefined function which can filter (accept or not accept) certain objects. It is a subclass of CallableScript. For example you can define a userdefined script in a specrepository which decides which spec files are loaded and which are not. This way you can exclude templates for spec files.
A FilterChain represents a chain or a list of Filter objects. All of them must return true before the FilterChain will return true.
Storage is the superclass for PostgresqlStorage and MemoryStorage. It contains a list of functions which should be implemented by a subclass. Storage is only used by the master.
This class implements the functions defined in Storage and stores everything in a Postgresql database. This way the data is also kept when you restart the master.
This class is not finished and currently does not work at all. It should be possible to use the master without a database for a limited set of spec files. With this type of Storage, all information about spec files and commands is stored in memory and is lost when you restart the master buildserver.
This class initialises a MemoryStorage or PostgresqlStorage object depending on the preferences of the user. You can use the getStorage() classmethod to get an instance of Storage. It is only used in the master.
PrepareSpecFileScript is a subclass of CallableScript. It wraps around a userdefined script which is used for a SpecRepository or for a Target. For example it can contain a script which downloads the sources for a spec file or which alters the Release tag of a spec file.
This class represents a list of PrepareSpecFile objects.
This class makes it easy to write another client for pydar2. It's a class which can connect to a master and call certain functions.
Rights contains some unique ids and abbreviations for each right of a slave or client. The ids and abbreviations must be the same as in the database.
TagsFile is the superclass of RpmFileTags and SpecFileTags. It contains general functions to get name,value pairs from spec files and rpm files. You can read normal tags like 'description', but also rpmforge tags like '# Authority' from spec files.
RpmFileTags can be used to get all the name,value pairs from an rpm. You can specify a string of parameters, for example '--define "el3 1"'.
SpecFileTags can be used to get all the name,value pairs from a spec file. You can specify a string of parameters, for example '--define "el3 1"'.
This class wraps some functions for accessing subversion repositories. For example you can get the 'svn last commit revision' of a file which can be used as a unique versionid of that file.
A target represents a repository of rpm files for which you want to build rpms. It's a bit up to the user what a target is. Most of it's functionality will be implemented in userdefined scripts probably. For example i'm using a target 'dries' now which contains all my rpm files, but it's possible to create different targets like 'rpmforge-stable' or 'rpmforge-unstable-us'. Currently you can add scripts to a target which alter a spec file before it is build so you can add a Packager tag for example.
This object contains a list of Target objects for a master buildserver. It is accessible from Config.
YumBasedBuildRoot is an implementation of the functions defined in BuildRoot. An object of this class is able to build rpms of a spec file for a certain distribution/architecture combination while using yum.