Re: Multiple transactions on multiple packages with rpm

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday 24 November 2003 07:08 pm, Jeff Johnson wrote:
> Rafael Angel Garcia Leiva wrote:
> >Dear all,
> >
> >We are developing a new toolsuite for the automated installation,
> >configuration and management of clusters and farms running Linux (see
> >http://quattor.org for more information). The Quattor information model is
> >based on the distinction between the "desired state" and the "actual
> > state" of nodes.
>
> Nod. Directly figguring the delta between starting and ending manifests
> is the best approach.
>
> >Regarding to software packages, we have a Software Package Management
> > Agent that reads a configuration file with the target packages, compares
> > it with the currently installed packages, computes the necessary
> >install/deinstall/upgrade operations, and invokes the packager with the
> > right operation transaction set.
> >
> >The problem is that the current version of rpm can not handle multiple
> >operations on multiple packages in a single transaction. Just imagine that
> >you want to install 'foo' and 'bar' RPMs replacing another RPM called
> >'foobar'. How can I order the operations respecting dependencies,
> > validate, and execute the complete operation in one go? This is currently
> > not possible in RPM (an 'rpm -e --test foobar' followed by 'rpm -i --test
> > foo bar' does evidently not work).
>
> As you have seen, there is no way to mix added and erased packages on
> the CLI even
> though rpmlib will handle mixed added/erased transactions.
>
> I immediately ask why you are trying to design around execing /bin/rpm.
> I suspect
> that you can/will do better linking rpmlib directly. Alternatively,
> rpm-python is
> an easier (i.e. more flexible, easier to change) implementation than Yet
> Another
> Executable.
>
> I'll be happy to help with either rpmlib or rpm-python programming if
> you want. There's also nothing
> wrong with a new executable in C either ;-)

Is it possible with current rpm-python to work with transaction sets? I mean, 
does the python lib exports the methods rpmtsAddInstallElement() and 
rpmtsAddEraseElement()? If not, do you have any plans to do so?

By the way, what happened with rpm-perl? Is it not longer under development?

> >What we have done to solve this problem is to develop a new software
> > packager (called rpmt) built on top of rpmlib to handle those lists of
> > transactions (if you are interested, you can download the source code
> > from
> >http://datagrid.in2p3.fr/cvsweb/edg-quattor/rpmt-4.2.1)
> >
> >As we have seen, rpmlib is ready to handle such lists of transactions. It
> > is possible to use rpmtsAddInstallElement() and rpmtsAddEraseElement()
> > within the same transaction set. So, it seems that it would be not very
> > difficult to extend rpm to handle lists of transactions. We really do not
> > understand why it is not possible to do with rpm something like:
> >
> >rpm -U package_1.rpm -e package_2
>
> The reason for *not* permitting multiple options factored this way is
> architectural, and has to
> do with popt aliases. The problem quickly becomes scoping multiple other
> options correctly,
> and that's much much harder to get right.
>
> >We would like to know if you think it is interesting to extend rpm in this
> >direction, or if you have plans to do so. Even, we offer ourselves to
> > provide a patch to rpm implementing the new functionality, if it is
> > necessary.
>
> When I get around to permitting mixed upgrade/erase on the CLI, the
> syntax will be
>      rpm ... -- +package_1.rpm -package_2
> and it won't maytter whether you invoke with major mode --install,
> --upgrade, --erase.
>
> That avoids many architectural problems, and sidesteps the problem of
> factoring multiple
> options on a per-package basis.

We prefer to use an imput file describing the transaction to run. The problem 
is that, according to our experience, the number of packages to 
install/deinstall/upgrade in one single transaction can be very large. Our 
rpmt tool is now in a production state at CERN (European Organization for 
Nuclear Research) computing centre managing more than 1200 nodes, running 
transaction sets with potentially tens or even hundreds of packages. This may 
cause problems if we use rpm's CLI.

> Meanwhile, add an RFE at http://bugzilla.redhat.com and attach rpmt.c
> (or supply a pointer)
> please, and I'll be happy to take a look at what you are trying to do.

Done! Your have an atachment with the rpmt source code (bug id 110905)

Many thanks for your help.

-- 
Rafael Angel Garcia Leiva
Universidad Autonoma Madrid
http://www.uam.es/angel.leiva


_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux