On Tue, 25 Nov 2003, Rafael Angel Garcia Leiva wrote: > 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? > I am pretty sure that is the case, but I don't know what the exact syntax is as I am a perl guy (-; There have been enough python scripts passing through the list (or other lists?) for me to know that the answer to your question is yes. > By the way, what happened with rpm-perl? Is it not longer under development? > I don't know the full story but basically support for it had to be dropped. There is another cpan module available, RPM2, which Chip Turner wrote that interfaces with librpm, and has the beginings of support transactions. I was the one that patched it to do this, but I also know there are some problems when actually running a transaction. Before I submitted the patch to RPM2 for transaction support, I tested doing simple installs and erases, but along the way I tried to update rpm itself with it and it died. At some point I would like to get this to work well, but if you are a perl hacker and would like to take to the next level I and I suspect Chip would be immensly greatful. Also, I would be more than willing to answer questions. > > >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. You can use manifests then, but I don't think manifests supports erasures? Jeff, am I wrong? I actually would like to be wrong, because then I can stop piling up erasures on the rpm command line. It would be really cool if a manifest supported both simultaneously as the underlying rpmts supports this just fine (I think (-;). > 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. > Actually, with current versions of bash I think you won't have problems at all, but since I have worked a lot with shells that have limitations on the size of the command line, I use manifests in our upgrade scripts. I think the manifest is a cleaner interface anyway (though, if I get RPM2 doing transactions well and reliably, you can guess what I would use instead). Cheers...james _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
