Re: Is possible RPM's sets?

[Jeff Johnson <jbj JBJ ORG>]

On Tue, Jul 10, 2001 at 01:21:12PM -0500, Tim Mooney wrote:
> In regard to: Is possible RPM's sets?, Juan Carlos Martín Cano said (at...:
> 
> >    With others installers you can create software sets. Each set is the
> >concept of RPM package, and all sets create the product. In this way you
> >can choose a set of sets, and to have a lot of different instalations
> >with one package. Is possible this one, with the RPM's?
> 
> RPM doesn't currently do what you're asking about.  I like the feature
> you're talking about too.  With RPM, you can make "related" packages,
> such as
> 
> 	krb5-server
> 	krb5-workstation
> 	krb5-devel
> 	krb5-docs
> 
> but there's no way in RPM itself to make a `krb5-bundle' that includes all
> of those sub-packages, and allows you to install all of them just by selecting
> the `krb5-bundle' for installation.
> 
> Some of the graphical front-ends for RPM do support this, though, if
> that's any consolation.
> 

Well, you can almost do the same thing as a package bundle or software set
using "manifests". Basically, anything that's not a package (i.e. with
rpm package magic in the 1st 4 bytes), will be read as a series
of glob expressions, honoring '#' comments. That means that you can do
do something like

	cat << GO_SYSIN_DD > mymanifest
	# This is a comment
	<wherever>/krb5-server-*
	<wherever>/krb5-workstation-*
	<wherever>/krb5-devel-*
	<wherever>/krb5-docs-*
	GO_SYSIN_DD

where <wherever> is a file path or URL, and then do, for example
	rpm -qp mymanifest
	rpm -Uvh mymanifest

To further confuse matters, manifests can chain, even through URL's as in
	cat << GO_SYSIN_DD > anothermanifest
	<whereever>/mymanifest
	GO_SYSIN_DD

	rpm -Uvh anothermanifest

I believe this is a quite powerful and useful concept for rpm, but here's
what is still gonna (ahem) need some work before rpm-4.0.3 is released:

Consider what happens with a typical use of rpm
	rpm -Uvh ftp://<wherever>/*

Yup, you can read a remote manifest that can chain you Somewhere Else Instead.
This can (and will) be insturmented with a CLI option, something
like requiring --manifest to "opt-in" before rpm-4.0.3 is released. Another
approach would be to prevent secondary chaining through URL's. I haven't
figgered what to do yet, as this is a pretty goofy unix command line thingy
that I know of no precedent for. (I'm not claiming invention, only ignorance.)

Another problem is detecting loops
	cat << GO_SYSIN_DD > manifest
	manifest
	GO_SYSIN_DD
That can be pretty simply handled by calculating a digest of a manifest
on the fly, saving already visited manifest digests, and dinging the
command if you ever revisit a manifest with the same digest.

Another tedious problem is
	bash$ rpm -qp /etc/sendmail.cf
	/etc/sendmail.cf: read manifest failed: Success
but that's just sloppy programming on my part so far.

Ideas?

73 de Jeff

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