On Tue, 2003-07-01 at 14:57, Pierre Fortin wrote:
> On 01 Jul 2003 14:45:24 -0700 James Sparenberg <[EMAIL PROTECTED]>
> wrote:
>
> > On Tue, 2003-07-01 at 13:37, Pierre Fortin wrote:
> > > On 01 Jul 2003 12:52:33 -0700 James Sparenberg <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > It works as expected.. the parent automatically dies and the child
> > > > continues it's run... Problem is when I put a similar case into an
> > > > RPM and it runs it. It hangs. RPM will not continue until child
> > > > runs it's course. And all the time that rpm #1 is open I can't
> > > > start installing rpm #2 (the rpm database does not multi-task.)
> > > > grrrr. Although rpm uses bash shell scripts it sure doesn't use
> > > > them correctly.
> > >
> > > Sorry, I don't follow all the threads... From what you say here, I
> > > think what you are up against is DB locking... and that won't be
> > > solved with multiple threads unless the DB allows it, which I doubt.
> > > Kinda sounds like the rpm DB is Linux' "registry" in this respect...
> >
> > correct and if I can figure out how to make rpm start the auto install
> > script ... then release it to continue on it's merry way I can cut
> > installation time for my company by 40% Or at least the time required to
> > find out if all rpms install correctly. (the rpm in question takes
> > about 80% of the total install time just waiting for the script is
> > spawns to run.) Not to disimilar to the situation where you install a
> > new kernel. It runs a number of commands (such as install_kernel) that
> > if there was a way to run them ... then let the rpm command finish while
> > they continue on their own. The system would be able to begin
> > installing the next rpm while the install_kernel command etc finished on
> > it's own. You know the old theory ... you can do anything with
> > software... we'll, I'm trying to prove just that. *grin*
>
> So you're gonna rip rpm apart and have it use separate DBs aligned with
> the package categories already defined by Mdk... Cool! :^) :^)
Not quite.... I'm trying to find a way to make rpm -Uvh spawn off
processes that allow the first rpm -Uvh to end, freeing up the rpmdb to
accept a new rpm -Uvh. kinda like
_ installation script for rpm1 running.
/
/
rpm -Uvh rpm1.rpm (rpm complets) _ installation script rpm2
\ /
\ /
- rpm -Uvh rpm2.rpm (rpm completes)
\
\
- rpm -Uvh rpm3.rpm
instead of the more linear process it is now. I don't want to get into
rpm itself... but rather figure out how to spawn independent processes
rather than dependent ones. Right now if in the rpm I put
%postin
nohup /usr/local/bin/autoinstallscript1 > &
RPM itself will wait no matter what for that command string to finish.
I don't want it to wait. I want it to do anything else it has to do,
finish and not care what happens to the above command string. I can do
this from a command line ... but for reasons beyond my ken when bash
commands are used in rpm they act differently.
On your point.. yes ... I agree that rpm could more affectively handle
the database. There is no reason why it should lock the db after it
figures out if all dependencies are met unless it's actively writing to
the db. Data can be gathered and written asynchronously as easily as it
could be done synchronously so why not... but that's another battle for
another day.
James
>
>
> ______________________________________________________________________
> Want to buy your Pack or Services from MandrakeSoft?
> Go to http://www.mandrakestore.com
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com
