2008/12/30 Peter da Silva <[email protected]>: > OK, I never really had to deal with RPM internals before, but it behaved > like an oddball packaging format with some kind of binary header, so I > assumed that's what it was... but no. It appears that the only supported way > to build an RPM is by having an actual installer, RUNNING it, and having RPM > pluck the result out of the system where you put it... at least that's what > RPMbuild looks like it's doing. You can't just create a spec file and a > directory tree that contains what you're going to package up, and say "OK, > make an RPM out of the stuff in this directory". > > And you can't even make it do the work in a custom directory without > changing a magic dotfile in your home directory. So if you want to make an > automated RPM build process that's running on a shared build server, you > can't do it when anyone else is using the thing. > > What kind of idiot would consider this hateful mess even vaguely a good > idea?
One of my favorite forms of hate related to RPM's has to do with its warped concept of the universe. You see RPM thinks that any given file can only have one source. And that if you want to say, upgrade a file in a package, you have to remove the old package first. Now this is just hateful behaviour, totally divorced from day to day reality. One does not purchase cars minus all the replaceable bits, and then install the replaceable bits later, that would be silly. Yet, if cars were distributed using RPM that is exactly how it would work, or rather not work. Imagine how heart surgery would work in RPM: "Would you like to uninstall human-v0.01 [Y/n]"? Yves -- perl -Mre=debug -e "/just|another|perl|hacker/"
