Re: [Rpm-maint] [rpm-software-management/rpm] Do not allow to divide by 0 in the expression evaluation (#833)
pmatilai requested changes on this pull request. See above, nice catch but please fix the error and commit messages. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/833#pullrequestreview-288012096___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Localize our chroot in/out operations to minimize time spent inside (#836)
@pmatilai pushed 1 commit. 746c9e310edd891101d454f7a0d4c65fe7fd862e Localize our chroot in/out operations to minimize time spent inside -- You are receiving this because you are subscribed to this thread. View it on GitHub: https://github.com/rpm-software-management/rpm/pull/836/files/518401829ff073649a5f19680e8203a402c32c4c..746c9e310edd891101d454f7a0d4c65fe7fd862e ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Localize our chroot in/out operations to minimize time spent inside (#836)
The primary motivation here is to consolidate all database accesses on one side of the chroot, currently it happens on both sides of the border causing all sorts of issues and limitations (such as preventing us from using more advanced modes of databases). As a positive side-effect, the sections where we potentially run inside chroot are more easily identifiable. Consolidating on the outside may seem counter-productive, to improve security it seems youd want to spend as much time *in* as possible, including database accesses. Unfortunately due to rpms access patterns and API promises, thats not really achievable (tried several approaches, run into as many dead-ends). Technically we could localize the chroot placement much further, but doing so would change the side for transaction callbacks, which could cause nasty breakage for our API users as various clients use those callback slots to update their own databases and logs. So the chroot spots here are selected to cover minimum possible code while preserving the chroot side of callbacks and plugin slots: RPMCALLBACK_INST_OPEN/CLOSE, ELEM_PROGRESS and VERIFY_* occur outside the chroot, everything else inside. Of plugin slots, init/cleanup and tsm_pre/post occur outside, everything else inside. You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/836 -- Commit Summary -- * Localize our chroot in/out operations to minimize time spent inside -- File Changes -- M lib/psm.c (66) M lib/rpmtriggers.c (12) M lib/rpmts.c (2) M lib/transaction.c (5) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/836.patch https://github.com/rpm-software-management/rpm/pull/836.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/836 ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] expression expansion (#834)
Here's my proposal:
1) turn off default string expansion in rdToken
This is an incompatible change, but it's clearly the right thing and I
can't imaging somebody
actually using this in a %if statement
2) Add optional expansion for the integer case
3) Add a new macro that does not expand the macro body in `doFoo`, but instead
calls rpmExprStr with a flag that enables expansion in rdToken.
We could use `%{( )}` as new macro, as proposed in the thread about the `?
:` operator.
4) Add '? : ' support to the expression expansion code
With that changes we can do `%{( %foo ? "%bar" : "%baz" )}`
Does that make sense? Should I create a pull request?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/834#issuecomment-531171559___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
