:
I cannot fathom why anyone would ever want to work directly with SRPMS like that, for any package.
Two reasons: 1) CVS tip is not reproducible (easily), and 2) it may be in undesirable flux.
In kernel terms, if I download 2.6.23 tarball and you download 2.6.23 tarball, we get the same thing. If config and gcc are factored out, we get the same result. But if I do git pull, you do git pull, we get different things. Heck one of them may even reject a patch that applies to the other one fine.
In case of Fedora, it’s even worse because CVS is no git. To try and convince CVS to produce you a useable tree for X11 before libpciaccess, for example, is an arduous task. I, for one, have no clue how to accomplish it. Moreover, I have no desire to bother when it’s so easy to download a suitable SRPM which is known to work.
And presumably if you ever want to update it you need to download a whole new SRPM and do it all over again, instead of just ‘cvs update; make $ARCH’.
You should do a cvs update -d, and even then I’ve been bitten by leftover configs before. In SRPM case, if you do “rm ~/rpms/SOURCES/*”, you may be sure that the result of rpm -i is going to build.
It’s true that in the long run SRPMs are unworkable for day-to-day hacking due to their sheer bulk. The multi-petabyte /mnt/redhat/dist is something remember vividly, if not fondly. However, I feel a certain trepidation and uncertainty every time I check out anything with a tag. And of course the first thing I do after the checkout is “make srpm”, then I run away from CVS as fast as I can.