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.

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.

I don't see why it needs documentation, apart from
the change in default being announced.

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

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.

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.

Yes.

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

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.

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.

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.

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

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

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

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

Hello Maintainers,
until recently I was using apt-get as I did for ages. Now in a
different bug report it was suggestes that I switch to apt, which I
did.

Now I discovered this bug, i.e. deb files are no longer stored in
/var/cache/apt/archives.

As the submitter, I really like the behaviour of keeping the files
there and I do not use autoclean.

At least on one occurance this was vital, when an upgrade broke net
connectivity (but only after next reboot). So I was offline and the
only chance I had was to use the older deb.

This is IMHO a crucial difference between apt-get and apt.

I read apt(8) and apt.conf(5), but could not find anything about this
missing behaviour.

So it clearly needs good documentation.

I clearly support the original submitter in all of his arguements,
especially:

For others reading this bug, this is most likely
APT::Keep-Downloaded-Packages "true";

Which I'm now trying (or switching back to apt-get).

Greetings

       Helge

Hello Maintainers,
until recently I was using apt-get as I did for ages. Now in a
different bug report it was suggestes that I switch to apt, which I
did.

Now I discovered this bug, i.e. deb files are no longer stored in
/var/cache/apt/archives.

As the submitter, I really like the behaviour of keeping the files
there and I do not use autoclean.

At least on one occurance this was vital, when an upgrade broke net
connectivity (but only after next reboot). So I was offline and the
only chance I had was to use the older deb.

This is IMHO a crucial difference between apt-get and apt.

I read apt(8) and apt.conf(5), but could not find anything about this
missing behaviour.

So it clearly needs good documentation.

I clearly support the original submitter in all of his arguements,
especially:

For others reading this bug, this is most likely
APT::Keep-Downloaded-Packages "true";

Which I'm now trying (or switching back to apt-get).

Greetings

       Helge

Hello all,
Am Wed, Sep 18, 2024 at 04:33:59PM +0000 schrieb Helge Kreutzmann:

No, this does not change anything.

Thus apt-get it is.

Greetings

            Helge

Hello all,
Am Wed, Sep 18, 2024 at 04:33:59PM +0000 schrieb Helge Kreutzmann:

No, this does not change anything.

Thus apt-get it is.

Greetings

            Helge

The option is correct, however the override is in binary::apt, so you
need to override the override:

binary::apt::APT::Keep-Downloaded-Packages "1";

Am Thu, Sep 19, 2024 at 07:02:30PM GMT, schrieb Helge Kreutzmann:

dito.
documented in this very bug report, but it seems like you missed
the finer details in the noise…

debian/NEWS says:
|   This can be changed by setting the apt configuration option
|    "Binary::apt::APT::Keep-Downloaded-Packages" to "true". E.g:
|
|  # echo 'Binary::apt::APT::Keep-Downloaded-Packages "true";' \
|      > /etc/apt/apt.conf.d/01keep-debs

Note that this is no longer shipped in the binary package as the
NEWS entry is from 2016 and debhelper helpfully decides that this
is no longer news to anyone and trims it like old changelog entries.


Note also that the apt(8) man page has a section about differences to
other tools and refers in it to the Binary scope of apt.conf(5).
So, if you are interested in the config differences:
| apt-config dump Binary::apt


Best regards

David Kalnischkies

P.S.: I do use that option myself, so I know that works and will stay
that way for the foreseeable future.

Hi,

So there is an override for an option configured by default? Can you add
that to the documentation for the option?

    Simon

Hello Julian,
Am Thu, Sep 19, 2024 at 09:39:53PM +0200 schrieb Julian Andres Klode:

Thanks, this works as intended.

Greetings

          Helge

Hello David,
Am Thu, Sep 19, 2024 at 09:55:28PM +0200 schrieb David Kalnischkies:

Ideally, I wouldn't have to look at the bug report. Maybe some (wiki)
page could list the difference for people migrating. This "feature"
cought me by suprise. And I was looking through apts man pages to find
out what was happening, but no avail.

This is not some kind of permanent documentation. It was valuable for
people back then, but now this needs a permanent home, like a man page
or some wiki page, preferrably linked from e.g. apt(8)

Yes, I saw that, but in apt.conf(5) I couldn't find any detail about
this.

This is a very helpful hint, and I would strongly support having these
two lines in apt(8).

Great.

Greetings

          Helge

I agree. Moreover, this is a bit surprising, because there is no such
thing for apt-get: "apt-config dump Binary::apt-get" returns nothing.

overrides the defaults, so only it has overrides.

The problem IMO is that these overrides take precedence over
the global options, in an optimal world the search order would look
like:

1.  Option
2.  Binary::<name>::Option
3.  <default value for Option>

We currently can't do that: The default values are initialized by
setting them if they haven't been set yet - only then do we parse
the command-line where we set the Binary:: options.

Fixing this requires adding a new member to record the "default"
value, and then using Binary:: to change the default setting, rather
than the global one.

Or something like that.

It would be nice.