On Thu, Jul 24, 2003 at 04:12:47PM -0400, Paul Iadonisi wrote:
On Thu, Jul 24, 2003 at 12:07:39AM -0700, Robert LeBlanc wrote:
[snip]
I'd like to see a more flexible, versatile approach in any "next-generation" RPM/up2date system, and that's what I'm trying to petition for here. Either a Gentoo-like system that can build applications at install time with user-specified options selected, or at least a means of making the option set visible somewhere within the RPM package, so that when updates are downloaded for those packages the up2date process can search for RPMs built with those particular options. I'm sure there are other solutions that would work as well, given a little time and thought, and a willingness to make changes on this level.
To be frank, I think you really are looking for something more like Gentoo. Red Hat is doing its best to handle the 95% - 99% use cases. In my own, somewhat biased opinion, I think they do a pretty good job of it. But I have run into similar things that you have (applying a mysql patch to sendmail and building the cyrus-sasl-mysql module as two examples).
There's room for moving closer to a Gentoo approach, but typically the problem revolves around a) how to set up a build system b) how to use rpmbuild to package
Both a) and b) are simple with a rpm package management domain, but entirely outside of the scope of rpm if/when you want to do your own thing differently.
If, on the other hand, you really feel this is a problem that doesn't exist, or one that would require more work to fix than you're willing to invest, just say so and I'll shut up. I'm only trying to help make the RPM/up2date system live up to its initial promise, and if indeed you believe it's as good as it can get I'll drop the matter and go back to my tarballs, or to Gentoo.
Although I don't think anyone at Red Hat is going to tell you 'shut up,' I don't think that rpm/up2date has ever included the promise of being able to account for custom changes users have made. Read the section in the release notes of the past several releases on the Ximian desktop for evidence of this.
Up2date (and rpm underneath it) depends solely on the concepts (N == name, E == epoch, V== version, etc) a) package N to choose what to compare with. b) "newer" as in EVR version comparison. c) whether to use rpm for software mgmt at all.
Both a) and b) are quite mangeable for customization. b) in particular pretty much means that you have to choose a release that is newer than the RHL starting point, but "older" than any release number that rpm is likely to choose. This preserves the ability to upgrade, see "vepoch" in the package building guidelines at http://fedora.us for a perfectly reasonable rule based release naming scheme that has the right properties.
The other piece that might be needed is to configure up2date to Never remove or upgrade this package. (i.e. because it's customised). Already there, breaks on paradigm shifts, but Red Hat does it's best to avoid aurprises. Sure there's surprises, NPTL comes instantly to mind, but there are as few as is humanly possible.
c) is insoluble in general, way outside the scope of rpm package management as currently implemented.
73 de Jeff