Author: Bobby Rockers

Getting In Deep with RPM

RPM is easily the most comprehensive packaging system for Linux.  The breadth of functionality and features in RPM continues to amaze me at times. Lately I have been working on getting some packages ported from our existing Redhat ES 3 infrastructure to Suse.  As a quick side note; we are not happy with Suse lately but at least they do not intentionally break KDE and ignore their volunteer community.  While RPM could, in theory, be used as a general package infrastructure for all RPM based system; the reality is something else entirely.  Packages from Redhat have required significant changes for me to get them working on Suse (the opposite is entirely true as well.)

A couple tools that have made porting easier have been perl.req and perl.prov.  Located in the /usr/lib/rpm on Suse 9, these two scripts take a list of files and return (through stdout) all required/provided perl packages for those files. Packages are only listed once and are presented in alphabetical order.

The GROUPS file for handling software categories in RPM is located in the /usr/share/doc/packages/rpm/ directory; while the RPM macros file (which is surprisingly similar to Redhat’s) is located in the normal installation directory of /usr/lib/rpm/macros. Here is a link to the January, 2005 edition of Suse Package Conventions.  I have downloaded a version in pdf form that can probably be found in my documents web page (see the VAULT side panel.)

A couple of Perl specific macros that only exist in Suse (and make building RPM packages much easier) are %perl_process_packlist, which does a bunch of cleanup work to the perl modules being built, and %perl_make_install, which handles different prefix installs depending on which version of Suse is being used. %perl_make_install is especially nice if you are trying to build a RPM for older and newer versions of suse in the same build environment.

RPM also provides similar macros (and requires/provides scripts) for Python. See the macros files for more details. Finally, the bible for all things rpm is Maximum RPM from rpm.org. The default macros like setup, prep, and patch are all defined there and are identical between distributions.

War & Peace

The Futurist is running a two part article (titled “The Winds of War, The Sands of Time”) discussing the relative state of peace in the world.  The article points out that from the metric of human beings killed in combat; the last couple years have been the most peaceful in recorded human history.  The reasons for this “”expansion of peace” are the usual suspects; expansion of democracy and an increase in overall absolute wealth worldwide.

The other interesting piece of data gleaned from the article is the wikipedia List of wars and disasters by death toll.  When I saw this page I had the same feeling as the one I got the day I first saw the History channel.  Something along the lines of “Ohhhh, crap!  There goes my free-time for the next six months.”  They even list the individual battles by death toll.

Please excuse me, I have some reading to do.

The Last Piece

The only thing keeping me from redirecting all the rockerssoft.com blog traffic to rockerssoft.org is a feature I have come to like; but never had for wordpress. That feature is my reading list plugin. Well, that is about to change. Now Reading is exactly what I have been looking for. As soon as I get a free chance to implement it; we will finally be moved in. Much like when we unpacked that last box at our new house…

…a year after we moved in.

Filesystem Synchronization

I have been looking at tools to synchronize my work machine, laptop, and home computer.  There are literally dozens of options for this on Linux but it looks like the best two are rsync and Unison.  Both are command line applications with GUI frontends available to them.  Specifically I have been looking at QSync which implements the rsync protocol internally and uses Qt.

Finally Found

Sometimes it is difficult to find the location of opensource software. It is not always available where you would look for it. I have been looking for the source code location of Adept for a while now (well, I haven’t wanted it so badly that I was willing to install Ubuntu.) Currently the only source copies are in KDE svn. Get adept from anonomous KDE svn this way:

svn co svn://anonsvn.kde.org/trunk/playground/sysadmin/adept

Software Testing Strategies

Test Smarter, Not Harder is an article by Scott Sehlhorst that covers software testing (the information can actually be applied to all forms of unit testing) and how to reduce the cost of application testing.  The fundamental idea is that if testing costs are greater than not testing then you are better off NOT doing the testing.   Therefor emphasis should be spent in reducing the cost of testing so it become practical to test more often.  Topics covered include automated testing, random sampling, pairwise testing, and N-wise testing.

Software Development
and Project Success

When I was growing up our family’s resources were less extensive than they are now, and as such, we sometimes had to do without some perks. One of these perks was a complete set of tools for home/car repair. Simple fixes like changing a battery would result in hours of work because of the inherit limitations of our tools; which ostensibly consisted of a hammer and a butter knife. Whenever I was brushing off the latest “injury” incurred while fixing something, my father would say to me, “Everything is simple if you have the right tool.” The better the tool is at doing a specific task, the easier it will be to complete that task. Ever watched “This Old House?” They had a tool to do everything! I didn’t even know they made adjustable-corner-rounded-cut-circular-door-saws with the optional digital level… cordless, if you are lucky. Heck, if I had a shop with 30 million dollars worth of specialized equipment, I bet even I could make something as fundamentally complex as a bar stool.

“Everything is simple if you have the right tool.”

This maxim (while not always true) is amazingly accurate in describing the modern development process. In fact, this is the reason I work on KDE (as opposed to the “other” Linux desktop environment.) Things are simply easier to do, are more productive, and more functional because the tool is designed better and focused specifically on desktop software development.

Today I ran into a series of articles by some application developers who I have come to respect. Their insight into the software development process will hopefully help give me some direction on future project management. Here they are will some selected quotes that stand out:

The strongest indication of a weak team is the realization that if you were to quit and start your own business, you wouldn’t try to poach any of your colleagues.

“Strong teams have almost impossibly high hiring standards. Strong teams will always leave a desk empty rather than settling for less than the best.”

“Examples of development hygiene include source code versioning, maintenance of an accurate bug or issue database, significant use of automated testing, continuous integration, and specifications that are kept current (whether incredibly detailed or high-level overviews).”

“A chicken is an individual who has significant authority over your project, but does not make a personal commitment to the success of the project.”

“And every time I’ve delivered software on schedule milestone after milestone, my influence and standing with stakeholders has grown. And every time I’ve missed a date, I’ve suffered, regardless of whether the late software was demonstrably better than what was originally planned for the missed date.”

“Documents such as specifications yield the same benefits of source control.”

“Discard all processes that are mechanically completed with little actual benefit. Tweak those that require more effort than necessary, maximizing the results while minimizing the effort.”