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.
probably need to talk with Jeff Johnson, or Paul Nasrat if you really want to pass an rpmts via some IPC mechansim. My first guess is you
really don't need to do that, but I obviously am not aware of your overall
architecture you are shooting for.
Cheers...james
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
_______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
