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

Bug#948892: apt does not store .deb files in /var/cache/apt/archives



On 2020-01-14 15:52:52 +0100, Julian Andres Klode wrote:
> On Tue, Jan 14, 2020 at 03:37:07PM +0100, Vincent Lefevre wrote:
> > On 2020-01-14 15:10:18 +0100, Julian Andres Klode wrote:
> > > If you installed the package, you don't need it anymore, and
> > > it's not going to help you revert to an older version, because
> > > it's the same version you just installed. Keeping it is
> > > useless.
> > 
> > You miss the point that with the next upgrade of the package,
> > it will no longer be the same version as the installed one.
> > If for some reason the next version is broken (which happens
> > from time to time), one may want to revert to the old version,
> > and the only way is via the .deb file.
> 
> By the next version it will have been removed by autoclean,

I repeat: I do not use autoclean.

> unless you have tons of disk space and don't use it. This seems like
> a bad assumption.

I have a total of 450 GB of disk space (SSD), which isn't even
"tons of disk space" with the current standards. As long as I
have free space, I can use it for .deb archives. When the disk
starts to become full, I can remove old .deb files... by date,
as this is safer than autoclean. So, now I have .deb files up
to 2017-04-19, which is more than enough (if an older package
is upgraded, then some working version should at least be in
stable, thus can be downloaded).

Note: At least, having a behavior different from aptitude does
not make much sense. That's why I haven't noticed the problem
until now (I use mainly aptitude, but I sometimes use apt when
I need --no-install-recommends).

> > > A more sensible approach for people who do want revert abilities,
> > > would be to keep $N versions of each deb in the archive, where
> > > $N might be 3.
> > 
> > Yes.
> 
> I think we should figure out if we want a different behavior
> here. Probably $N versions and $maxdiskspace or something, and
> then implement that, and give it a sensible option.

The best for me would be a limit of the free disk space.
For instance, make sure that the free disk space is not less
than 30 GB. And when the limit is reach, treat that as an
error (or a warning + confirmation) to let the user decide
what to do (remove some files, decrease the limit, etc.).

> > > > Perhaps that's the default option
> > > > 
> > > >   Binary::apt::APT::Keep-Downloaded-Packages "0";
> > > > 
> > > > below, but it is not documented.
> > > 
> > > I don't see why it needs documentation, apart from
> > > the change in default being announced.
> > 
> > *All* configuration options need to be documented somewhere,
> > and man pages, if not containing the full documentation, should
> > at least give a reference to the full documentation. Announces
> > are useful, but do not constitute documentation.
> 
> All options are documented/listed in the configure-index. But no,
> they should not all be documented. Just because there are a ton
> of knobs, does not mean they are all supported.

Keep-Downloaded-Packages, which is an important option, is not
documented anywhere.

> I think a lot are not knobs you should turn, they are temporary
> workarounds to enable you to keep your system uptodate while
> you adapt to the new behavior. This should go away and be moved
> into compat levels.

Anyway it would be useful for the user to know what he should not
modify.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Reply to: