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

2020-01-14 Thread Vincent Lefevre 
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  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

2020-01-14 Thread Julian Andres Klode 
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:
> > On Tue, Jan 14, 2020 at 02:59:25PM +0100, Vincent Lefevre wrote:
> > > Package: apt
> > > Version: 1.8.4
> > > Severity: normal
> > > 
> > > I've installed some packages with "apt install ...", but the
> > > corresponding .deb files are missing from the /var/cache/apt/archives
> > > directory (contrary to packages installed via aptitude).
> > > 
> > > This is either a bug or an undocumented behavior (both in the
> > > man pages and in /usr/share/doc/apt-doc/guide.text.gz). I also
> > > cannot see the reason of such a behavior: .deb packages are
> > > useful if one needs to revert to the previous version of a
> > > package.
> > 
> > It's a feature since 1.2 (see debian/NEWS).
> 
> I see (that's rather old, and I missed that, probably at some time
> I was not using the apt command at all).
> 
> > 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, unless
you have tons of disk space and don't use it. This seems like a bad
assumption.

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

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

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.

FWIW, Binary::$foo is a scope that gets moved into the root scope
after option parsing, so it can set per-binary options. This
does not work sensibly, as if apt sets Binary::apt::bar, and
you set bar, the default in Binary::apt still overrides it
- I don't like it.

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

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

2020-01-14 Thread Vincent Lefevre 
On 2020-01-14 15:10:18 +0100, Julian Andres Klode wrote:
> On Tue, Jan 14, 2020 at 02:59:25PM +0100, Vincent Lefevre wrote:
> > Package: apt
> > Version: 1.8.4
> > Severity: normal
> > 
> > I've installed some packages with "apt install ...", but the
> > corresponding .deb files are missing from the /var/cache/apt/archives
> > directory (contrary to packages installed via aptitude).
> > 
> > This is either a bug or an undocumented behavior (both in the
> > man pages and in /usr/share/doc/apt-doc/guide.text.gz). I also
> > cannot see the reason of such a behavior: .deb packages are
> > useful if one needs to revert to the previous version of a
> > package.
> 
> It's a feature since 1.2 (see debian/NEWS).

I see (that's rather old, and I missed that, probably at some time
I was not using the apt command at all).

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

> Compare that to autoclean which deletes precisely the
> versions you'd be interested in keeping (the ones no
> longer downloadable).

That's why I don't use autoclean (but at least, autoclean usually
keeps the installed version).

But in unstable, since the new version replaces the old one, the
previous .deb file is no longer available for download, unless it
happens to be the version in testing or stable.

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

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

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

2020-01-14 Thread Julian Andres Klode 
On Tue, Jan 14, 2020 at 02:59:25PM +0100, Vincent Lefevre wrote:
> Package: apt
> Version: 1.8.4
> Severity: normal
> 
> I've installed some packages with "apt install ...", but the
> corresponding .deb files are missing from the /var/cache/apt/archives
> directory (contrary to packages installed via aptitude).
> 
> This is either a bug or an undocumented behavior (both in the
> man pages and in /usr/share/doc/apt-doc/guide.text.gz). I also
> cannot see the reason of such a behavior: .deb packages are
> useful if one needs to revert to the previous version of a
> package.

It's a feature since 1.2 (see debian/NEWS).

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.

Compare that to autoclean which deletes precisely the
versions you'd be interested in keeping (the ones no
longer downloadable).

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.

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

-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer  i speak de, en

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

2020-01-14 Thread Vincent Lefevre 
Package: apt
Version: 1.8.4
Severity: normal

I've installed some packages with "apt install ...", but the
corresponding .deb files are missing from the /var/cache/apt/archives
directory (contrary to packages installed via aptitude).

This is either a bug or an undocumented behavior (both in the
man pages and in /usr/share/doc/apt-doc/guide.text.gz). I also
cannot see the reason of such a behavior: .deb packages are
useful if one needs to revert to the previous version of a
package.

Perhaps that's the default option

  Binary::apt::APT::Keep-Downloaded-Packages "0";

below, but it is not documented.

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$";
APT::NeverAutoRemove:: "^linux-image-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-5\.4\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-headers-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-5\.4\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-5\.4\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-modules-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-modules-5\.4\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-modules-extra-5\.4\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-5\.4\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-unsigned-5\.4\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-5\.4\.0-2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-5\.4\.0-2-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-5\.4\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-modules-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-5\.4\.0-2-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-5\.4\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-5\.4\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-modules-.*-5\.4\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-tools-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-5\.4\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-cloud-tools-5\.4\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-buildinfo-5\.4\.0-2-amd64$";
APT::NeverAutoRemove:: "^linux-source-5\.4\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-source-5\.4\.0-2-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-modules";
APT::VersionedKernelPackages:: "linux-modules-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "linux-image-unsigned";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::VersionedKernelPackages:: "linux-cloud-tools";
APT::VersionedKernelPackages:: "linux-buildinfo";
APT::VersionedKernelPackages:: "linux-source";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::AutoRemove "";
APT::AutoRemove::SuggestsImportant "false";
APT::Clean-In