-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Paul Howarth wrote: | On Fri, 2005-03-11 at 04:03 +0000, D. D. Brierton wrote: | |>On Thu, 2005-03-10 at 20:26 -0600, Eric Vought wrote: |> |> |>>I am going to need to rebuild Apache shortly to change the suexec |>>docroot to /home, in line with what VirtualMin requires. This, in and of |>>itself, does not scare me. What does make me a bit nervous is the |>>prospect of doing this without breaking all of the various RPM |>>dependencies and hosing my system the next time the httpd package is |>>updated. |>> |>>Is there a preferred method for rebuilding Apache on FC3? If I install |>>from source, how do I get all of the other packages which depend on it |>>to work correctly? In the past, I would have built the custom version in |>>/usr/local, but nothing (e.g.: the init scripts, WebMin, etc) expects to |>>find it there. If I modify the build configuration in the SRPM and |>>rebuild/reinstall, how do I keep a YUM update from clobbering the |>>customized binary? Is there a "yum |> |>I am very interested to hear what others more knowledgeable than myself |>have to say about this. I personally think that your best bet is to |>build custom RPMs yourself, rather than just compiling from source and |>installing via the "configure ; make ; make install" route. |> |>You'll still need to worry about whether updates from Fedora would |>replace your customised packages. One possibility would be to set a high |>epoch number on your custom RPMs, so that updates from Fedora never |>replace them. That might cause dependency problems with other packages |>that you don't want or need to build yourself, but maybe it won't. |>Someone more knowledgeable about RPM and how epoch works might be able |>to enlighten us. The trouble is that you will need to regularly manually |>track the Fedora updates for security and bug fixes, and manually |>rebuild your RPMs with your custom spec file from the updated SRPMs. |> |>I don't see any other convenient route to doing what you want to. If you |>start compiling key components of FC yourself and installing them |>without using RPM you're going to end up in a world of pain. | | | I agree with Darren that tweaking the httpd SRPM is the way to go. But | then I always say that ;-) | | I wouldn't alter the Epoch: because someone else could always out-Epoch | you. | | You can stop yum clobbering httpd by using one or more "exclude" | directives in your /etc/yum.conf. If some package comes along that | requires a later version of httpd than yours, yum won't be able to | install/update it because it won't be able to resolve the dependency, | and so the update won't happen. You'll need to keep an eye on your yum | output to spot when this is happening so that you can update your own | package to match the updated Fedora httpd package, but that doesn't get | updated very often so it shouldn't be too onerous a task. If you create | a single patch file to cover the differences between your build of httpd | and the Fedora build, you may even get away with applying the same patch | to subsequent Fedora SRPMs to implement the same set of changes, making | it an easy update to do. | | Paul.
OK, what I have done is rebuilt the RPM with the changes. I actually only need to change httpd-suexec, but it is built along with half-a-dozen other packages out of the httpd srpm. I took the time to set up a non-root RPM build environment as I will have to keep up with updates myself. (I hate compiling things as root- dangerous).
In order to (hopefully) prevent auto-update, I changed the package release in the spec file to add "di" to the end. This seems to be enough to keep YUM from trying to mix the packages, but it still provides "httpd", so other package dependencies appear to be fine. Because of this, I had to install all of the rebuilt packages, not just the one I needed.
I have a spec file patch. In fact, I have two. The first one is just the changes to make the suexec-docroot parameratizable at the top of the spec file. Previously, content_dir controlled *both* the Apache docroot and the suexec docroot. In my version, there is a separate parameter which defaults to content_dir. I also add the configured docroot to the httpd-suexec RPM package summary. The second diff has the suexec_docroot customized for my needs and changes the package release.
It seems like my first patch might be generally useful. What do I do with it? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCMeWyGqlqMhx2Xb0RApgkAJ909egYvlBfaJWqWT3qKrUVgqPejACeOH0f 9BuYZa80DliGD/5H1nUxNFE= =9w1a -----END PGP SIGNATURE-----
