It's either a blessing or a curse that I've never had cause to build an RPM down to the spec file until this evening. Well, really, I theoretically should have done this back during the summer, but it's the side job, and there was a faster way to get the new servers running (build a few things like PHP by hand and install, rather than package, them) than either dealing with the absence of PHP 5 packages for CentOS 4.5 (I didn't pick the production environment in either case, so shut the fuck up) or satisfying some other distributions' RPM requirements.
(This is the point where several of you will suggest Debian. Trust me: get fucked. Debian's concept of stable and my clients' concept of what's required to support their application diverge by roughly 24 months. Certain other members of the peanut gallery will make noise about FreeBSD 5 + ports. I will disagree with that contingent less, but This Is Not My Baby. Nor is it reasonable for any party involved for me to support it full time.)
So, but, the goal here is having all required applications, at the revision level necessary for the application to function (securely) packaged, and reproducible in a clearly documented command line when it's time to turn up a new clustered web/db/index/etc server. Ideally by PXE booting or similar. That is absolutely an acheivable goal, but it does require that things like PHP be internally-maintained packages, and so we come to building RPMs, and so I come to reading this steaming pile of zebra dung:
6.8. Files
This is the section where you must list the files for the binary package. RPM has no way to know what binaries get installed as a result of make install. There is NO way to do this. Some have suggested doing a find before and after the package install. With a multiuser system, this is unacceptable as other files may be created during a package building process that have nothing to do with the package itself.
Italics, emphasizing their colossal ignorance, theirs, not mine.
These clowns have never heard of the –prefix flag for GNU configure? I find that improbable. They've never heard of mtree(8)? They go so far as to assert that find(1) can't, under any circumstances, actually solve this problem. No, rather, I should install things, dig through the output from that manually, and concoct, by hand, a list of files (and the permissions on those files) as installed. They have got to be fucking kidding me.
Yeah, sure, I run around with the title of Unix Systems Adminstrator. I don't have a business card (nor do I care for one), but if someone in HR were to choose what it said, it'd say that. BUT. Fucking BUT. This is one of those situations where the computer gets to do the goddamn math. That's why my employer (whoever they happen to be that hour) paid for it… that is, The Computer. What's it do? It computes. It does math. What's keeping track of piddling things like file paths and permissions? Yeah: math.
It so happens that I have no problems doing this relatively quickly on my own, but the fact remains that I absolutely should not have to. rpmbuild? It doesn't build jack shit. It reads a configuration file and fails without exact instruction. It should read a config file to locate the source and the configure options, test build, create a file list for install, regenerate a configuration file for end state configuration and installation, then build a package including target installation locations. But, apparently, it's too dumb for that. NetBSD's pkgsrc (which also works on all BSDs, Solaris, and Linux) isn't too dumb for that. FreeBSD's ports tree isn't too dumb for that. The community-provided macports for Mac OS X (drawing from each of the former two) isn't too dumb for that. Debian's .deb packaging infrastructure isn't too dumb for that. RPM? Apparently: still too dumb for that. What the fuck?
Post a Comment