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. > In the interim; is this a showstopper? Do we generally do the right > thing (e.g. without changes, can we package up using the existing > rpm files?) Obviously 2.0.54 was mispackaged as well, it's minimum > apr package dependency should have been 0.9.6 apr, not 0.9.5. It's not a showstopper no. In the mean time I have been producing SRPM source archives that contain the original pristine httpd source, and a "fixed" httpd.spec file. They are available from the binaries/rpm/SRPM directory in the distribution directory. Regards, Graham --
