Re: [FYI] RPM and dependency check

[Jeff Johnson <jbj JBJ ORG>]

On Mon, Aug 07, 2000 at 10:46:03AM -0500, Carlo Marcelo Arenas Belon wrote:
> i just get to :
> 
> http://www.osopinion.com/Opinions/AmyLear/AmyLear1.html
> 
> something that got me thinking about was (talking about dependendy check):
> 
> "now, having worked with many a source package, I've become quite attached
>  to the way a well-prepared configure script can poke its way through a
>  system"
> 
> for sure, autoconf does some great work inspecting "building dependencies"
> on a system basis for getting a package to build nicely.
> 
> should this kind of "dependency check" be built over RPM (maybe adding a
> plugin dependency script on /usr/lib/rpm/find-dependency) or we are
> supposed to rely on --nodeps every time we want to install a binary RPM on
> a different Linux distribution?
> 
> actually, i keep an RPM archive of "only" RedHat packages on
> http://sajino.terra.com.pe/pub/linux/redhat/, getting binary RPMs for
> another distribution is usually just annoying (because of the dependency
> problems)
> 
> for a really simple package i mantain, something as : 
> http://sajino.terra.com.pe/sqmgrlog/ is needed if you wan't to give a
> succesfull roadmap on installing a binary package on several Linux
> distributions.
> 
> anyway, i would love to hear your toughts regarding this
> 

There are several issues mentioned in the URL above:

1) dependency resolution, of both build and install varieties.
	rpm packaging is as good (or as bad) as the dependencies
	are. What's unfortunate, at the moment, is that the only
	way to get dependencies correct in a package is by looking
	at a full universe (read: complete set) of distribution install
	dependencies.  That also only works for a single distro, however,
	as each distro uses sligltly different dependency glue.

	Build dependencies are still in their infancy (read: lightly used)
	and will require a fair amount of work to preserve the fiction
	that source packaging is noarch. For example, for hysterical
	reasons, glibc on alpha provides libc.so.6.1 while i386/sparc
	glibc provides libc.so.6. That means the equivalent of
		%ifarch	alpha
		BuildPreReq: libc.so.6.1
		%else
		BuildPreReq: libc.so.6
		%endif
	will be needed to do the Right Thing. There are even messier issues
	down here as well.

2) build/install autoconfiguration
	autoconf/automake work quite well, although they are rather slow.
	There is little reason to duplicate the functionality in rpm,
	particularly for install dependencies, as the tests would be quite
	slow and the dependencies that would be added in order to perform the
	autoconf-like tests would be quite painful.

	I can see a need for build dependencies, as rpm, unlike autoconf,
	has a database that could be used to verify that the build
	system was correctly prepared before starting a long build.
	Basically, this could/would be encapsulating config.status
	output in rpm packaging, and identifying all executables/files
	used during a build.

3) changing the package format
	I believe that the comments in the URL are quite naive wrto
	the need to create a new package format. YMMV.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@jbj.org	(jbj@redhat.com)
Chapel Hill, NC