Thanks Paul and David.
To simplify a frequently seen halt of `apt upgrade` I have this example.. I
had to remove keepsolidinc.list
from /etc/apt/sources.list.d. Then apt update proceeds. Here is the error I
get with that source list in place:
*Hit:1 http://archive.ubuntu.com/ubuntu
<http://archive.ubuntu.com/ubuntu> - InRelease
Hit:2 http://security.ubuntu.com/ubuntu
<http://security.ubuntu.com/ubuntu> --security InRelease
Hit:3 http://archive.ubuntu.com/ubuntu
<http://archive.ubuntu.com/ubuntu> --updates InRelease
Hit:4 http://archive.ubuntu.com/ubuntu
<http://archive.ubuntu.com/ubuntu> --backports InRelease
Ign:5 http://apt.keepsolid.com/ubuntu
<http://apt.keepsolid.com/ubuntu> - InRelease
Err:6 http://apt.keepsolid.com/ubuntu
<http://apt.keepsolid.com/ubuntu> - Release
404 Not Found [IP: 144.217.71.199 80]
Reading package lists... Done
E: The repository 'http://apt.keepsolid.com/ubuntu
<http://apt.keepsolid.com/ubuntu> - Release' does not have a Release
file.
N: Updating from such a repository can't be done securely, and is
therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user
configuration details.*
For the size estimation, I understand it is an estimation, and there could
be guesswork, but I would posit that if the estimate is even roughly
correct, a user most likely will not want to proceed, because the
consequences greatly outweigh the benefits of proceeding.
This is because once a disk is filled, `apt remove` will not undo the
changes until the install is complete. This creates an impossible
situation, ie. apt cant remove without space, but install cant proceed
because there is no space.
This problem is most relevant today with users heavily relying on VMs where
shrinking a disk is often problematic, so creating an image with the least
amount of freespace is highly useful, because images are often cloned
many times for backup and progression. This means repeatedly bumping into
this "impossible situation".
It seems a simple solution to just not proceed when the estimated install
space exceeds the free space. It is already calculated. And the edge cases
will more likely than not benefit from not proceeding by default. This is
because the cost of a false positive is much, much less than getting into a
catch-22 of disk space, getting stuck, and not being able to undo what apt
just did, even following the recommended --fix-broken which wont work if
the disk is full, which is many times presented because of the disk being
full. I'm not sure I see many situations where having to use a flag to
proceed would harm the vast majority of users.
Thank you
On Sun, Oct 9, 2022 at 5:37 AM David Kalnischkies
wrote:
> On Fri, Oct 07, 2022 at 09:33:28AM +0800, Paul Wise wrote:
> > On Thu, 2022-10-06 at 10:54 -0700, xaq xaq wrote:
> > > Hi, how do I submit a suggestion to the Apt team? I've tried to
> > > register on their website (https://salsa.debian.org/apt-team/apt).
> >
> > You can report a bug via the Debian BTS:
> >
> > https://www.debian.org/Bugs/Reporting
>
> Our¹ "website" mentions at the end of our general information blob:
> | Discussion happens mostly on
> | [the mailing list](mailto:de...@lists.debian.org)
> | ([archive](https://lists.debian.org/deity/))
> | and on [IRC](irc://irc.oftc.net/debian-apt).
> | Our bug tracker as well as a general overview can be found at
> | the [Debian Tracker page](https://tracker.debian.org/pkg/apt).
>
> (in markdown so you can see the direct pointers). It is actually our¹
> README file in the version control system, we don't have a website and
> hence none is given in the Homepage field.
>
> ¹ "our" as in: I am one of two active apt developers.
>
>
> > > - Have an option to ignore failures in any source.list file.
> > > This will allow updates of security repos to proceed.
> >
> > This makes it sound like you need to update your apt sources for the
> > changes to the security archive that happened in Debian bullseye:
> >
> >
> https://www.debian.org/releases/bullseye/amd64/release-notes/ch-information.en.html#security-archive
>
> Apart from what Paul said (and is btw an other indication that "we will
> write it in the release notes and everything is smooth sailing from
> there on out" still means a lot of support questions. I stopped counting
> how often I pointed to that release note section…):
>
> Please tell us the EXACT and COMPLETE update output you are seeing.
> In the security-archive example an 'apt update' will fail with error
> messages and such about the bad archive, but all the other "working"
> archives will be updated as usual and subsequent apt calls will use
> that information. The failure is hence already "ignored&q
