[lug] building SRPM's

[D. Stimits]

David L. Anselmi wrote:
> D. Stimits wrote:
> [...]
> 
>> I really cringe every time I have to think of packaging.
> 
> 
> Perhaps you've discovered that software integration is different than 

Trust me, I've known for a very long time how hard integration is. 
Several years back one of my jobs was to create installers on windows 
using InstallShield. $800 and a custom language for no other purpose 
than installing on windows. It got very very complicated fast, 
especially if making installs for NT and non-NT at the same time.

> software development (which isn't exactly programming).  And that 
> software integrators are good people to know.  I don't really expect a 
> software developer to do more than make a tarball of the latest release 
> that configures and makes install.

Ideally, I plan to learn to become an integrator, at least among 
RPM-based platforms. I see no other way if I plan to contribute anything 
outside of some specific job. When I first started using linux, the 
kernel was 1.0.9, and nobody cared for anything but a tarball. Nowadays, 
I see a lot of good software passed by just because it doesn't come in 
the right package...free software now requires marketing skills, and by 
far the bulk of that skill is easing installation and administration.

> Send me a link to your latest release and I'll see if I can build it 
> (hmm... should I do that on an Alpha, too?)  I can give you some 
> feedback on your portability.

The library is not really done. It works with a minimal set of features 
now, and is bug-free (some may laugh, but I know it is quality code 
without memory leaks/crashes, and it does what it should do). At this 
stage I'm planning on getting a minimal rpm that works on FC2 through 
FC4, and do not yet care about other platforms (once features are done I 
will care). But I'll probably take you up on your offer after I'm 
satisfied with features and basic packaging.

> I'd consider doing a Debian package for this (I'm more interested in 
> that than in programming, and if your package is simple it shouldn't be 
> that hard).  But the Debian guys say libraries are a bad place to learn 
> packaging.  Well, who knows?

The package is very simple, it's just a wrapper for command line 
options. The thing that is unusual about it is that it is 
self-documenting (think of autoconfiscate for command line options), and 
makes command lines capable of self-validation. E.G., you register an 
option, and the brief help is automated...tell it about restrictions, 
and it'll provide feedback to people who enter the wrong command line. 
I'm also going to integrate in man page creation templates so that users 
of the wrapper can take the same command line registrations and 
autogenerate a man page.

Goal: RAD for command lines that leaves not one hint of ambiguity to end 
users for lack of documentation, while taking less time for the 
programmer to use it than to not use it. I've been working on SQL import 
tools, and find I spend way too much time parsing command lines...I 
could hack it and have it breakable or give mysterious errors, but I 
find this unacceptable. When I'm done, a wrapped command line will be 
polished and easier to use with full docs than the hack would be (but 
applies only to C++ authors, although it would be easy to write a C 
wrapper lib). This seems like the perfect opportunity to learn RPM 
packaging, since it is so simple (lacks dependencies, works with old or 
new glibc and libstdc++).

> I'd expect you to be using autoconf before you start making SRPMs.  And 
> to have a release process.  And to keep your spec files or whatever 
> (that's distro specific) out of the standard release.  (Not that my view 
> of the world has anything to do with reality.)

Someone mentioned this already (Hugh), rpmbuild has a way to use a spec 
file that is in a tarball, so I was wanting to keep a spec file in the 
tarball. Now if autoconf had a cousin "autospec" which would take a spec 
file from one RPM distro and generate one for any other RPM distro, this 
would be even more useful. Well, long story short(er), this library is 
C++, it requires g++, and not much else. It uses getopt_long, which I 
will likely replace later...getopt_long is not part of any POSIX 
extension, and is not portable (likely many *NIX systems have it 
available, but some won't, and definitely non-NIX won't). On most any 
*NIX with getopt_long and libstdc++, autoconf isn't even needed. But, 
that's a different story...

D. Stimits, stimits AT comcast DOT net