Package bullshit!

Is there some rule out there that 99% of all RPM SPEC files need to be fixed to do things in a sane manner? You know, RPM provides macros for the install prefix, ./configure, and a whole bunch of other shit.

I swear, I spend half my time repairing fucked SPEC files when I’m playing with a new program….

About Kevin Sonney

Kevin Sonney - who, contrary to popular opinion was NOT raised by wolves - grew up in central North Carolina. He fell into the technology field by accident in 1991, when he gave up the wild and crazy lifestyle of an on-air AM radio DJ to become a mundane technical support monkey. The technology industry has never really recovered from this. Kevin has worked for such names as IBM, Red Hat, webslingerZ, and Lulu Technologies (we won't mention the ones that didn't survive the experience). He currently works as a Linux Administrator for Apptio. In his spare time he rescues stray animals and plays video games with his two sons. His wife, we're sad to say, helps him get past the really hard bits. Kevin is still not very mundane, he just got better at hiding it.
This entry was posted in Uncategorized. Bookmark the permalink.

7 Responses to Package bullshit!

  1. ratnix says:

    “What I wouldn’t give to have a SPEC generation tool that didn’t suck,” says the person who went from 9 to Fedora without realizing pine had been ganked.

  2. clubjuggler says:

    So, you’re probably tired of hearing me talk about it by now, but that’s another thing I like about mandrake packages. They make liberal use of macros. Mandrake even includes some macros in their rpm packages that red hat doesn’t (like a %make macro that will figure out how many processors the build computer has and add the appropriate -j option). I don’t remember the last time I made a spec file without using macros…

  3. alchemist says:

    Actually, I spent about 3 hours on Sunday fixing a SPEC file that had been written for mandrake that used some very unhappy macros that only exist on mandrake. the goal of a spec file is something that works cross platform, right?

  4. alchemist says:

    Actually, I spent about 3 hours on Sunday fixing a SPEC file that had been written with macros that only exist on Mandrake. Any time a packager writes a distro-specific spec file, they earn a very special spot in the hell I am building.

    I’m trying my damnedest to write specs that work on all distros, and not just Mandrake or RHEL or Fedora or $RPM_BASED_DISTRO. What’s the point of a source RPM that ony works on one distro?

  5. alchemist says:

    Yeah, that’s probably the problem – SPEC generation tools write these fucked up things, and the authors don’t know any better.

    Fixed one earlier today that used / as the temp install dir. Nice was to gack a system by building the package as root….

  6. deviant_ says:

    Yes, there is precisely such a rule. Specfiles suck in really impressive ways, and packagers don’t tend to notice most of them.

  7. clubjuggler says:

    So, rpms that are specifically targeted to a particular distribution should stick the lowest common denominator? Come on. If the spec file specifies that it’s a mandrake package, don’t be surprised to see mandrake specific macros in the file. It’s not like red hat can’t grab them and put them in their macros file too. It’s all GPL.

    The point of a source rpm that only works on one distro is that some distros may have different packaging policies than other ones. For example, how are shared libraries packaged in Red Hat? In mandrake, all shared libraries must be in an rpm package that is formated with the name “lib“. That package should contain only the shared library. Development files (headers) should be in “lib-devel” and any other files the package has should be in “-%version”. Mandrake has added macros to make doing this easy. IIRC, Red Hat doesn’t follow this convention, so I wouldn’t expect them to have those macros. But, since they don’t follow that convention, I wouldn’t expect the rpm to make a lot of sense on Red Hat anyway. It’s specifically setup for mandrake policies and shouldn’t necessarily be cross distro (unless, of course, you can convince Red Hat to do the sane thing with their shared library rpms. ;-)

Comments are closed.