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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/packaging -- packaging mailing list packaging@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/packaging
