Request 145 was acted upon.
_________________________________________________________________________
URL: https://rt.openpkg.org/id/145
Ticket: [OpenPKG #145]
Subject: rc issues
Requestors: [EMAIL PROTECTED]
Queue: openpkg
Owner: rse
Status: open
Transaction: Correspondence added by rse
Time: Mon Jul 14 15:01:30 2003
________________________________________________________________________
> [...]
> The recommended way to set up the environment is with
> eval `$opkg_root/etc/rc --eval all env`
> and I've got some issues with that:
>
> 1. I noticed a whole lot of extra lower case variables are being
> set,
> being pulled in from the %config sections of al the rc.d scripts,
> even those that don't have a %env section. They're not being
> exported, but I really don't like them being left set in the
> user's environment. I'm not sure what to do about all of them,
> but I do have a partial solution (below).
>
> 2. The eval statement takes a noticeably long amount of time, and
> I'm
> not too happy about that either.
>
> 3. The %config sections of all the rc.d scripts are being read in
> for every file. If they were only read in once, especially only
> those that have %env sections, that could help with reducing
> the time.
>
> What do you think of the following patch (against the current CVS rc
> version 1.24)? In our case, it cuts the total time down by about 25%
> and the size of the tmpfile down by about 80%. It reduces but does
> not
> eliminate the extra unexported variables left set in the user's shell.
> [...]
Thanks for your patch and sorry for the delay in responding.
I've now reviewed it and also took it over in a slightly adjusted way.
1. To move out the %config generation out of the loop is a great
idea. I've done it now exactly as in your patch.
2. To look at only those files with %env sections is not possible,
because all sections in all scripts by definition should be
able to see all config variables of all other scripts. An example
are packages which use the %config variables from the "MTA" packages.
So, this extra optimization with your "grep" approach is not possible.
Nevertheless the moving out of the %config parsing already dramatically
speeds up processing, so I think we should be already happy about this.
3. The lowercase <package>_xxx variables are nasty, yes. But I don't
know how one could solve this. Because the stuff is "eval"ed in
the caller's shell, we cannot use sub-shells inside the scripts.
With a subshell we could get rid of the %config variables
being passed to the caller, but at the same time the resulting
variables (for which we're evaluating!) would be lost, too.
> Also, what do you think about having a way for having the "tmpfile"
> pre-generated each time any package is installed or upgraded, and
> having the users invoke that each time rather than running rc
> directly?
> That would eliminate the speed problem. I'm thinking of having them
> invoke
> $opkg_root/etc/init.sh or $opkg_root/etc/setup.sh or something like
> that.
Yes, that's an idea we already had in another OpenPKG ticket.
This definetely could dramatically speed up processing again.
I'll perhaps try to pick up this idea later for OpenPKG 2.0.
Thanks for your contribution.
--
Ralf S. Engelschall
OpenPKG Project Leader
[EMAIL PROTECTED]
