On Dec 19, 2008, at 11:04 AM, Ralf S. Engelschall wrote:
> On Fri, Dec 19, 2008, Jeff Johnson wrote:
>> (resent, dunno where the 1st message went)
> I don't know, never seen on the list...
>> I kind of like the idea of using a '@' before a file path as an
>> "attention" marker to increase the file validation checks, and so I'm
>> likely to refactor the functionality out of rpm and into popt-1.15 as
>> part of simplifying rpm configuration/initialization.
>> At the same time, I will probably add a new poptReadConfigFiles()
>> method whose argument will be a colon separated list of configuration
>> file paths to read.
>> Any other opinions?
> As long as the particular security check (here rpmSecuritySaneFile
> for RPM_VENDOR_OPENPKG) embedded into POPT can be optionally still
> overridden from within RPM (in case one needs some additional checks
> a different error message or whatever) I'm happy. Perhaps an optional
> callback does the trick.
I really like the in-band '@' "attention grabber". I 'spose I can expose
a global callback vector if you wsh to override poptSecuritySaneFile()
for some purpose down the road ...
Basically I'm just gonna merge the code from rpm -> popt, removing
RPM_VENDOR_OOPENPKG, no other change.
The ulterior motive is unrelated to popt, but rather refactoring
RPM's use of popt. I haven't a clue anymore of what gets read from
where in RPM, and so am hoping to bury some of the functionality that
I __DO__ understand while composting the rest of RPM initialization.
I'd really like to not have to engineer Yet Another callback into popt,
what's there is bad enough to maintain. But I can try for a table
driven callback if you prefer to a global vector override, I'm
not particularly fond of globals either.
Thanks for comments.
73 de Jeff
Received on Fri Dec 19 17:15:04 2008
- application/pkcs7-signature attachment: smime.p7s