I'm glad you've had a learning exercise. But may I point out that the
"cpan2rpm" and "cpanspec" tools do a more thorough job of this, and
you might benefit from reviewing those and expanding them rather than
trying to write your own tools from scrartch?
On Tue, Jan 28, 2014 at 3:02 PM, Gene <dadealeus(a)yahoo.com> wrote:
I recently posted regarding a software I developed that I wanted to
get some
feedback on (
https://github.com/genereese/togo).
I didn't hear back from anyone, so I figured that I might need to expand on
exactly what information I was trying to garner from the post.
A bit of my background:
I started building RPMs about 7 years ago when I worked for the U.S. Court
Systems. I had to take various third-party and in-house software
(backup/restore/encryption programs, etc.) and figure out how to package
them (and their installation processes) as RPMs.
When I began, I was immediately overwhelmed by the immense amount of dry,
disorganized information regarding creating even a simple "hello world"
style RPM. I quickly found that there didn't seem to be a whole lot of
standardization among the build environments of people who posted on the
subject.
After a great many hours devoted to reading mounds of information and trial
and error, I was able to create my first RPM. However, it quickly became
apparent that my build environment was disorganized, hard to re-use, and
just plain ugly.
After months of even more trial and error, I settled on a system which broke
up the various components of RPM creation into (what I feel) is a much more
manageable structure (something I feel most new packagers lack).
I basically wrote a wrapper around the rpmbuild binary which handles all the
busy-work and allowed me to focus on the layout of the software I was
packaging.
My RPM authoring steps are (roughly) as follows:
1) Creation of a new RPM project for whatever software I want to package up.
This process sets up some sqlite helper databases to keep track of various
things, sets up your .rpmmacros for the project you are currently working
on, provides a 'spec' directory (will expand on that in a minute), provides
a 'root' folder (which represents '/' once the RPM is installed), and
folders for the meta-data which is generated during the build process.
2) Moving my software into the project.
I lay out my files as I would want to see them once the RPM has been
installed. So, if I had a config file and a daily cron job that needed to be
run, I would create new directories under the above-mentioned 'root'
directory (root/etc and root/etc/cron.daily) and then I would copy/move my
files into the new directories.
3) Flag my files for inclusion in the RPM.
I run a command to flag the files with their type (REGULAR, %config, %doc,
etc). This command records my preferences into one of the sqlite databases
that was created earlier so that when I actually want to build the package,
everything is read from the database and the package is built accordingly.
4) Modify my spec file.
A default spec file with common options and a pre-configured %build section
(configured for my project's environment) was generated when I created the
project. It is compiled from several files, all listed under the 'spec'
directory.
For example, the 'spec/header' file contains the most used information
regarding version/release/summary/description/requirements/etc. - and
separates off the other portions of the spec into other files; such as
'spec/pre' 'spec/changelog' etc.
5) Build the RPM.
This is the part of the script that does the meat of the work. The script
first takes the 'spec' directory and compiles it into a fully-functioning
spec file, populating the %files list from the database (where you flagged
your files, earlier). Once it generates the spec file, it tars up the 'root'
directory tree and takes care of placing the spec/source/etc. into the
red-hat required meta directories before calling 'rpmbuild -bb' against the
generated spec and then moves any resulting rpms into the 'rpms' directory.
The entire directory structure may then be checked into a version control
system and you may simply update and rebuild the project as you desire.
My goal was to provide an easy to manage/read/reuse system for introducing
people to RPM building while still allowing them to be productive (not
having to spend several hours just getting something that works, but is
ugly, unmanageable, and difficult to expand or re-use).
If you are so inclined, please try it out and let me know your thoughts:
https://github.com/genereese/togo
I am specifically attempting to figure out if there is some horrible flaw in
this setup that I am overlooking; any thoughts in that realm would be
greatly appreciated.
Regards,
Gene Reese
--
packaging mailing list
packaging(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/packaging