At 12:58 2003/07/23, Jeff Johnson wrote:
On Wed, Jul 23, 2003 at 12:20:38PM -0700, Robert LeBlanc wrote:
> The problem at the root of all this is that if I ever need to rebuild
> anything from sources, I break the auto-update chain for that
package. The
> fact that I've applied a (developer-defined) customization effectively
> means I can no longer have security updates and bug-fixes applied without
> doing them by hand. What I'd rather see is a system flexible enough to
> detect (e.g. by reading the equivalent of a config.status file) the
> configuration options that were used to build a package in the first
place,
> and then applying these to updated sources--*or*--have it search for a
> binary distribution that was compiled with those specific options enabled.
>
> The latter may in the end be the more feasible option for RH. Essentially
> have the RPM information itself keep track of what options were used to
> compile the package, so that people who need a set of binaries compiled
> with options X, Y, and J can search on this basis, and make this a
> requirement for any auto-updates.
There are two problems here:
1) how the build system is set up.
2) how the package was built.
The build system for RHL is setup by using build dependencies for all but
a handful of packages like gcc and make.
How the package was built is encoded in the spec file, and rpm by design
guarantees that each and every rpm started from a spec file, virgin sources,
etc and ran to completion in some build system.
Yes there is no explicit config.status, basically because there is no need
if you are using RHL packages, or custom modifications of RHL packages,
or simple additions to RHL distros.
Sorry, but I feel a bit like I've been "talked in circles", here :)
I've
been describing the problems inherent in "custom modifications of RHL
packages", namely that any need to rebuild anything from sources (e.g. to
recompile a package with a different set of configuration options) breaks
the auto-updating capability for that package. I'm confused by the last
sentence of your response, though, which seems to imply that there's no
problem here at all. Could you clarify that a bit more?
I confess to being an old-timer, having used Linux since kernel 0.99.12
when *everything* had to be assembled by hand. I'm well used to the
process of downloading a source tarball, configuring and building the
sources, and installing packages that way. When RPM came along I was
initially impressed--package installation was about to become a whole lot
easier and more streamlined, I thought. This is certainly true for "out of
the box" installations, like for mass-deployment on workstations, but for
servers I've simply determined that RPM and its auto-updating facilities
are just false hopes--I can't (and therefore don't) use them, as too much
customization tends to be required for server apps.
The downside of doing everything manually, of course, is that I now have to
keep abreast of bug and security fixes myself, and apply them all by hand
to my sources, rebuild them, and reinstall them. I'd really like the
convenience of the auto-updating facility--and would find it worth paying
for--if it could actually work for me. The fact that it can't unless I
straightjacket myself with "standard" binary installations is frustrating.
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.
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.
Robert LeBlanc