[Rpm-maint] Feature Proposal: Identify if a Package is actually being used

[nick at notashutin.com]

Dear All:

 

I am new to this forum.  I am a capable coder, so I’m not going to ask you to deliver my idea.

I would like feedback, though, in case:

1.	You think my idea is poor
2.	You think it belongs in a standalone tool instead of rpm as a feature
3.	It’s already been tried, and I’m just unaware 😊

 

Explanation of need/desire:

A.	Home user: I want to be sloppy on install of favorite linux, and just install “all” (or, many, many package groups).  This will reduce install timeline / be more convenient…instead of me having to go through and hand-curate 500 packages or less, I can just grab 1500 packages.  But then, I don’t want to have to update all 1500 in the future, because that’s slow.  If only there was a way to install sloppily, but then uninstall the unused packages after a 30-day burn-in period…
B.	Business user: I get nagged all the time by my vulnerability management team to patch package after package.  If only there was a way to identify factually what packages I *need*, so that I can uninstall all the others, and not have to patch them…make my security team happy (and actually improve security…)

 

Proposed solution:

                Develop a means to track which files are actually being “used” on a system, and then relate them to packages, and then uninstall packages not being used.

 

Current thought on “how” to implement:

                I noticed there is a “Verify” function in RPM.  I noticed that it is harvesting & comparing mtime for each file in a package, which means that it is already calling stat(), and could therefore also make use of “atime”, without any extra call to the O/S to get data.  

 

Concerns/caveats with this approach:

i)                    Atime may be changed through various means that don’t really mean that something was “used” by the system in a meaningful way.

Assuming there are situations where a package may contain a library (e.g. gnome module to extend functionality, like pdf parsing), and you have never actually “used” it, but the fact it’s a library means it auto-loads into memory means the atime will be changed… thus incorrectly reporting on actual package use…I’m hoping this situation only produces a small quantity of false-positives, in which case the minimal development time requirement to meet the majority of my goal justifies accepting the false positives.  If this issue is more pronounced than I’d like, then I assume I’d have to look for another way.

ii)                   The current 9-character indicator of the Verify files in package function doesn’t have any unused future placeholders, so modifying “Verify”, per se, may create support problems for other scripts, so I imagine it may be most useful to modify the Verify function to simply have a separate function that returns an extra line as suffix to the total function (e.g. last line of output change) that indicates “Yes, package is used” or “No, package is not used”, rather than per-file output of atime analysis. (or add extra command-line-option to explicitly modify the 9-character indicator to 10 or more characters  (some to possibly be placeholders for other future use)

 

If you’ve read this far, thank you.

Feedback, please?!

Agree/disagree on need/motivation?

Agree/disagree on using rpm as the means of resolving need?

Agree/disagree on use of atime/modifying existing verify code?

Other suggestions for me?

 

Best regards

-NICK

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180609/c318ff7e/attachment.html>