On Fri, 30 Apr 2004, David D. Hagood wrote: > On 04/30/2004 12:24 PM, James Olin Oden wrote: > > > Yes, I think the info is on rpm.org, but Paul Nasrat probably knows for > > sure. You can usely catching him on #rpm at irc.freenode.net, or he may > > just reply (-; > > > > IRC is not an option through the corporate firewall, so that options out. > > > > Hmmm...I was pretty much thinking you would only pass enough information > > for the work script to build the transaction (i.e. you would not build it > > in the non-root script, only gather enough info to build it). You > > Here's the use-case: I'm designing an embedded system, based upon Linux and > using RPM for updates (and APT for update, but that's another slogfest). > > The idea would be that the normal instrument program, which runs as a > non-priviledged user, would query the APT repositories, generate a list of > available changes, interact with the user to determine what was to be installed, > validate the selections are sane, then invoke the root-equiv process to do the > work (and get status reports via some form of IPC TBD RSN). Think "synaptic" but > as a part of the overall instrument program rather than a seperate program. > > It would seem to me that the non-priv side would need to do all the conflict > resolution in order to insure that nothing stupid will happen (IF conflict THEN > show_user_the_Problem) before invoking the root process. > > Now, I suppose I could just pass off the list of new packages to install/upgrade > and assume that the root process will reach the same conclusions as the non-root > process. But we all know ASSUME makes an ASS of U and ME. > That seems reasonable, I am not sure but I think you can run rpmtsOrder() and rpmtsCheck() as a non-privileged user, such that you could do this before sending the data on what packages should go in the transaction to the priviliged process. Cheers...james P.S. I am going to test the above...but I am experiencing some minor difficulties. _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
