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