Abstract Package Build Description
İçindekiler
Introduction
"Abstract Package Build Description" is a tool to create Generalized XML files from source tar-balls. The Generalized XML file generated using this tool can be used to generate the control files for any packaging system(That's our aim!! but it may or may not be true right now), using the appropriate parsers. At present, The tool includes parsers for RPM and Debian control files and is able to generate SPEC files that can be used as it is to generate RPM packages using rpmbuild.
The tool is created by Rajagopal N, based on the concept of PWIZ, the work of Stanislav Brabec as the prototype.
Download
Get it as a Rubygem or from SVN
Install
For a system-wide installation, please use the gem.
Syntax: gem install <gemfilename>
A rake version would be soon made available for the SVN. Till then run the SVN version locally.
User Manual
The main program can be initiated by the command apbuddy
The name APBuDdy was chosen as it resembles the acronym of the project title, viz., APBD, and the tool is intended to be a buddy for packagers to build Abstract Package Build Description.
User Interface Fundamentals
A onetime screen for choosing your expertise in packaging on your first run. It is asked for the system to decide whether you would be able to answer certain questions. This setting can be later changed from Extras Menu->Change Profile.
If a question is found to be of a higher level to your expertise level, the guess made by the system for that question would be taken as your answer and would be shaded.
Incase you feel that you know the answer for the question better than the system. you would just need to click on the checkbox corresponding to the question(at the right corner), and type in the answer that you feel is appropriate.
Extras Menu
Add Command
This interface can be used to
1) Add a command to be executed at some part of the build process.
2) Add an Extra Source/Patch to the package build process.
A command based phase can be added just by typing in the series of commands into the multi-line text box, and the name for the phase in the LineEdit provided for Name.
To add an Extra Source or a Patch file, a syntax like @Source@@<source-path>@ and @Patch@<patch-level>@<patch-path>@ has to be used respectively. These templates can be generated by clicking on the "Add Source Template" and "Add Patch Template" respectively.
While adding any of these phases, the position where the phase needs to be inserted can be set by selecting the relative position to an existing phase, by using the two drop down list boxes next to the text box provided for feeding in the Name.
Finally the "Add" button should be pressed to commit the created phase.
The rest of the user interface is simple and intuitive. You just need to fill up the fields shown at each step and click next and wait, to succesfully complete the packaging work.
Issues
The user interface would become non-responsive for sometime when the package is being built. Users, please bear with it. Threading would be properly implemented in the future versions, or MVC would be adopted to correct that. The user interface would become responsive again once the background process gets completed and control is given back to the UI.
Question Fields
Package Name - The Name of the package (Typically the name source tarball till before the version number starts).
Source File - Path to the Source tarball (Local path or URL).
Version - The software's version.
Release - Increment this everytime you repackage the software.
License - The License under which the software had been released.
Group - Used for placing the menu item appropriately based on the category to which the software belongs.
Distribution - The distribution for which the current packaging is done.
Architecture - Processor architecture (i386, i586, ppc, etc.).
Section - Normally used for debian Packaging, to group the package under an appropriate category on the apt repository
Maintainer - Name of the person who would typically be maintaining the software (May be your name ;))
Summary - A one line description about the package (Typically 4-5 words)
Description - A more detailed description of the package (Each distro have their own formats. Check your distro's description format if you are making a formal package to be submitted to the distro's repository)
Configure Arguments - Incase you need to give any arguments to the configure script, set them here. (To get a list of all such arguments, wou would go to the source folder and have a look at the output of ./configure --help)
CFLAGS and CXXFLAGS - Optimization flags for the gcc compiler. Set these only if you are well aware of what you are doing. If set incorrectly, the build may fail.
Packager Name - Whom to contact for issues or suggestions related to the package? (To be included in Changelog)
Packager Email - How to contact the packager?
Changes - Changes made to the current release (relative to the previous release. To be included in Changelog)
Scriptlet XML File - If you have any XML file containing XML scriptlets like <if distro="foo" version="bar"> <Parameter1>foo</Parameter1> <Parameter2>bar</Parameter2> </if>. You may use it to adhere to the different formats used for specifying the Description of the package, Group to which it belongs etc. where the fields are distro specific, or wherever you find its usage appropriate.
General concepts
Phases
The build process is divided into several phases of which the default list includes get_file, unpack, perl_configure(Running Makefile.PL to generate the makefile if it is a perl package), gnu_configure (If GNU autoconfigure enabled), make and install.
New custom phases may be added by the users by following the steps mentioned in Add Command Section
As far as the users are concerned, phases may be considered as any series of steps that the user feels should be atomic.
Steps
Each phase would typically consist of a number of small steps.
For example, get_file would consist of steps like
1) check whether the package path is local path or a URL
2) if local path, copy it to the source directory, if URL, download it, and then copy it to the source directory.
Developer Manual
Would be ready soon.
Contributing
Anyone interested in the project may feel free to start contributing to the project. Feel free to add your name to the list of developers when you have contributed something to the project and feel that you have become one of the developers for this project.
Anyone looking forward to start contributing would first read the Developer Manual to understand the various files and modules in the program.