Graham Leggett wrote:
William A. Rowe, Jr. said:The problem is that packaging is almost a 20/20 hindsite game. There's no way we should expect that all of these many platform specifics can all be maintained pre-release. That's why, in the Win32 .msi case, there is a seperate httpd/httpd/win32-msi/trunk/ containing the win32 packaging flavor. It doesn't get fixed for a specific release until we know exactly what needed to be fixed :) I'm concerned that the current .spec solution is wrong; it's very platform specific (platform meaning deployment mechanics, in this case, I'm not slamming non-unix rpm implementations). Perhaps we rejigger the tree to httpd/ package/ roll-release/ win32-msi/ rpm/ pkg/ Thoughts?The spec file needs to end up as "httpd.spec" in the root of the tarball so that "rpmbuild -tb httpd-2.0.55.tar.gz" works, so keeping it in a separate tree isn't going to work properly. The problem remains though - people change stuff within the tree, which affects the packaging, and this only surfaces when a release is rolled.
So... is it unreasonable in README.RPM to point the user to obtain the current httpd.spec/httpd.in from /dist/httpd/httpd-2.0.55-rpm-src.tar.gz which would be grabbed from svn httpd/package/rpm/, and drop it into the unpacked httpd-2.0.55 source tarball, in order to package? Bill
