[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#1058043: marked as done (automatic cleaning should (always) be enabled by default)

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 --- 
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 --- 
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 Kalnischkies

Attachment: signature.asc
Description: PGP signature


--- End Message ---
Reply to: