Your message dated Tue, 12 Dec 2023 16:21:09 +0100 with message-id <20231212152109.xwi2ry6p6jk3rzcf@crossbow> and subject line Re: Bug#1058043: automatic cleaning should (always) be enabled by default has caused the Debian Bug report #1058043, regarding automatic cleaning should (always) be enabled by default to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 1058043: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1058043 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: automatic cleaning should (always) be enabled by default
- From: Ian Jackson <ijackson@chiark.greenend.org.uk>
- Date: Mon, 11 Dec 2023 16:42:41 +0000
- Message-id: <[🔎] 25975.15361.174885.250423@chiark.greenend.org.uk>
Package: apt A friend's laptop's / had become full. I found 9 gigabytes of uselessly retained ancient debs in /var/cache/apt/archives. "apt clean" fixed the problem. I wondered why my laptop doesn't do this and a small amount of digging found an etckeeper commit from 2017. (See below.) Presumably I discovered this wasn't happening on my laptop and thought that it was somehow the result of something weird about my setup. But evidently not, since my friend's install is much more vanilla. My friend usually uses a GUI package manager. I could enquire as to which one. I usually use "apt" and sometimes "apt-get" aned never use a GUI package manager. I don't know if the cache would still be being maintained properly without my local change - ie, I don't know if the bug I experienced in 2017 would happen to *me* now, but it doesn't seem likely that anything has changed very much given the bug reports I saw. IMO something should ensure that files in /var/cache/apt are eventually deleted. I don't know if there is a thing that is supposed to do this, but if there is it doesn't always work. It probably ought to be part of src:apt, since it's code in that package which is creating these files. So that is why I'm filing this bug here. I searched the BTS for (archived and unarchived) bugs with "clean" in the title. Most of them seems to be bug reports (or feature requests) relating to the behaviour of `apt clean`. I found #160743 which is a report of the the same outcome, which was closed after having been only partially resolved. The mechanisms may be different nowadays. Partly, I am filing this bug to document my workaround. Apparently, it was sufficient, since `cd /etc && git grep -i clean apt` doesn't show anything else. So, my workaround is as follows: Create the file /apt/apt.conf.d/50actually-clean containing just this one line: APT::Periodic::AutocleanInterval 7; Ian. commit a6030b5ee990c826550fe5c530c54215817bdf65 Author: root <root@zealot.relativity.greenend.org.uk> Date: Mon Oct 9 02:12:17 2017 +0100 daily autocommit diff --git a/.etckeeper b/.etckeeper index 9167d07..b47e059 100755 --- a/.etckeeper +++ b/.etckeeper @@ -434,6 +434,8 @@ maybe chmod 0444 'apt/apt.conf.d/01autoremove-kernels' maybe chmod 0644 'apt/apt.conf.d/05etckeeper' maybe chmod 0644 'apt/apt.conf.d/20listchanges' maybe chmod 0644 'apt/apt.conf.d/20packagekit' +maybe chgrp 'ian' 'apt/apt.conf.d/50actually-clean' +maybe chmod 0664 'apt/apt.conf.d/50actually-clean' maybe chmod 0644 'apt/apt.conf.d/50apt-file.conf' maybe chgrp 'ian' 'apt/apt.conf.d/55aptsquid' maybe chmod 0664 'apt/apt.conf.d/55aptsquid' diff --git a/apt/apt.conf.d/50actually-clean b/apt/apt.conf.d/50actually-clean new file mode 100644 index 0000000..8f59382 --- /dev/null +++ b/apt/apt.conf.d/50actually-clean @@ -0,0 +1 @@ +APT::Periodic::AutocleanInterval 7; -- Ian Jackson <ijackson@chiark.greenend.org.uk> These opinions are my own. Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.
--- End Message ---
--- Begin Message ---
- To: Ian Jackson <ijackson@chiark.greenend.org.uk>, 1058043-done@bugs.debian.org
- Subject: Re: Bug#1058043: automatic cleaning should (always) be enabled by default
- From: David Kalnischkies <david@kalnischkies.de>
- Date: Tue, 12 Dec 2023 16:21:09 +0100
- Message-id: <20231212152109.xwi2ry6p6jk3rzcf@crossbow>
- In-reply-to: <[🔎] 25975.15361.174885.250423@chiark.greenend.org.uk>
- References: <[🔎] 25975.15361.174885.250423@chiark.greenend.org.uk>
On Mon, Dec 11, 2023 at 04:42:41PM +0000, Ian Jackson wrote: > My friend usually uses a GUI package manager. I could enquire as to > which one. I usually use "apt" and sometimes "apt-get" aned never use > a GUI package manager. I don't know if the cache would still be being > maintained properly without my local change - ie, I don't know if the > bug I experienced in 2017 would happen to *me* now, but it doesn't > seem likely that anything has changed very much given the bug reports > I saw. In 2016 (so, even before your change) apt 1.2~exp1 released with a change described in the debian/NEWS as: | After packages are successfully installed by apt(8), | the corresponding .deb package files will be | removed from the /var/cache/apt/archives cache directory. The entry is a bit longer, detailing that this is NOT happening for apt-get or any other tool by default, but you could enable it if you so choose and if its fits your usecases. The timer based cleanup remained a possibility as well of course, which perhaps suited your usecase better if you still use apt-get by hand. Neither (nor any other way) can really be enabled by default unconditionally for everyone and everything using libapt. > IMO something should ensure that files in /var/cache/apt are > eventually deleted. I don't know if there is a thing that is supposed That "something" is the user – in that case the user of libapt usually by proxy of some program. apt(8) choice is to delete them after use, apt-get(8) gives its users explicit control over the matter. The timer as another front end can be configured to call clean at times. There are a lot of other ways tailored to the actual usecase(s). We have no idea if and how other front ends do it, but we also have no idea how other front ends and users use the cache, so we can't manage the cache for them either. As an example: Various users mount the cache into s/p/cow/…-build and expect it to work, so removing the deb files on install makes that completely pointless. Cronjobs never run in chroots, they happily run on the main system while my chroots are busy accessing them through. Various users with local sneaker-based network implementations. And that is only the tip of the usecases-iceberg any "obvious" default change in libapt usually reenacts the Titanic story with. So, this report is not actionable for us and as such I have to close it; again, as you found yourself previous attempts to change the default with pretty much the same arguments against it and various suggestions and even implemented features to opt into for front ends and users alike. Please don't open unactionable considered-resolved bugreports to document what you consider workarounds but are actually configuration choices for your system(s). You should ask your friend what tools (s)he is actually using and see how the tools behaviour can be improved (or if they is holding it wrong by e.g. using apt-get). There are certainly many options, but they sadly don't work for everyone. Best regards David KalnischkiesAttachment: signature.asc
Description: PGP signature
--- End Message ---