Talking about HEAD towards rpm5, not rpm4.x. Ralf and me examined the repository today.
We instantly applied the simple rule "do not put generated files into the repo" at our sole discretion and cleaned up some things [1]. Hope there is consensus on this item which is self-evident for us. Next step was to dig into the libs where the repo carries copies of 3rd party code. The build process supports the use of either external or internal libs. The internal libs carry RPM specific patches, rendering use of the external libs likely useless. Also configure picks up all libs that exist, not supporting explicit enabling and disabling. Not everyone needs DB and SQLite and elfutils are vastly useless on every Unix but Linux. A related issue is that vendor branch feature is not used consequently. The db code seems to have been unpacked and committed as if it were a local app. It will be hard to merge the self created patches into the next vendor import. Assuming that local modifications are needed for the libs I recommend to a) drop support for external libs entirely and stick to the internals, b) teach configure to explicitly enable/disable features, c) revamp all 3rd party files to consequently use a vendor branch, enabling reimport and local patch maintenance and d) stay close to upstream and properly tag imports to weed out bugs and security incidents or at least have a solid base to patch against. Objections? [1] http://rpm5.org/cvs/chngview?cn=8323 ... 8330 ______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
