From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1AE7B385800B; Thu, 28 Jul 2022 13:59:19 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1AE7B385800B From: "woodard at redhat dot com" To: libabigail@sourceware.org Subject: [Bug default/29425] New: fedabipkgdiff doesn't prune cache Date: Thu, 28 Jul 2022 13:59:18 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: libabigail X-Bugzilla-Component: default X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: woodard at redhat dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: dodji at redhat dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: libabigail@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Mailing list of the Libabigail project List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2022 13:59:19 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D29425 Bug ID: 29425 Summary: fedabipkgdiff doesn't prune cache Product: libabigail Version: unspecified Status: NEW Severity: normal Priority: P2 Component: default Assignee: dodji at redhat dot com Reporter: woodard at redhat dot com CC: libabigail at sourceware dot org Target Milestone: --- fedabipkgdiff leaves package files in ls ~/.cache/libabigail after runs. Th= is can build up and take up a lot of space. I know that mine is a rather extre= me case but I currently have 66Gb of space taken up in=20=20 /home/ben/.cache/libabigail/ I think that fedabipkgdiff needs to implement some sort of cache pruning policy. One heuristic, that may be good enough is if it completes with no e= rror then it deletes its cache. That way it would be quick and easy to go back a= nd look at problem cases without downloading the packages again but in the most likely case, where there are no problems, the cache is kept reasonable. This seems to be different than: 21568 or maybe something is wrong with the current behavior. --=20 You are receiving this mail because: You are on the CC list for the bug.=