Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1210242 > unrolled thread

Bug#1079710: aptitude: "Immediate dependency resolution" must be optional

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1079710: aptitude: "Immediate dependency resolution" must be optional Matthias Urlichs <smurf@smurf.noris.de> - 2024-08-26 18:40 +0200
    Bug#1079710: [Aptitude-devel] Bug#1079710: aptitude: "Immediate dependency resolution" must be optional Julian Andres Klode <jak@debian.org> - 2024-08-26 19:20 +0200
      Bug#1079710: [Aptitude-devel] Bug#1079710: aptitude: "Immediate dependency resolution" must be optional Matthias Urlichs <smurf@smurf.noris.de> - 2024-08-26 21:40 +0200

#1210242 — Bug#1079710: aptitude: "Immediate dependency resolution" must be optional

Package: aptitude
Version: 0.8.13-5
Severity: important
X-Debbugs-Cc: smurf@smurf.noris.de

I'm trying to update a rather complex development system from Bookworm to
Trixie, i.e. through the 64-bit time transition.

The machine has three architectures installed, most libraries
are (historically) not marked as autoinstalled, and I have a bunch
of self-built packages of various historical state.

In this sort of situation it's really common for the autoresolver to not
find a solution. The problem is that attempting to manually resolve the
transition causes the "immediate dependency resolution" attempt (which
aptitude unconditionally performs whenever you change a package's state)
to take arbitrarily long. I'm seeing 30+ seconds *each time I press + or -*,
and that's on a >2-GHz 8-core workstation with a heap of RAM. Getting from
600 to 50 broken packages took me *two days*.

Thus, I'd like to (urgently) ask you to add a way to *turn this immediate
resolution thing off*, via some config option.

The current situation is untenable; updating nontrivial systems to Trixie
is going to be a *lot* of fun, for some non-empty subset of them, if this
isn't fixed.

The change should be backported to Stable, for obvious reasons.

-- System Information:
Debian Release: 12.5
  APT prefers testing
  APT policy: (850, 'testing'), (500, 'stable-security'), (500, 'oldstable-security'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (300, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, arm64, armhf

Kernel: Linux 6.1.0-18-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages aptitude depends on:
ii  aptitude-common           0.8.13-5
pn  libapt-pkg6.0             <none>
pn  libboost-iostreams1.74.0  <none>
ii  libc6                     2.38-13
ii  libcwidget4               0.5.18-6
ii  libgcc-s1                 12.2.0-14
ii  libncursesw6              6.4-4
ii  libsigc++-2.0-0v5         2.12.0-1
ii  libsqlite3-0              3.40.1-2
ii  libstdc++6                14-20240201-3
ii  libtinfo6                 6.4-4
ii  libxapian30               1.4.22-1

Versions of packages aptitude recommends:
ii  libdpkg-perl    1.21.22
ii  sensible-utils  0.0.17+nmu1

Versions of packages aptitude suggests:
pn  apt-xapian-index                <none>
pn  aptitude-doc-en | aptitude-doc  <none>
pn  debtags                         <none>
ii  tasksel                         3.73

-- debconf-show failed

[toc] | [next] | [standalone]

#1210249 — Bug#1079710: [Aptitude-devel] Bug#1079710: aptitude: "Immediate dependency resolution" must be optional

On Mon, Aug 26, 2024 at 06:34:23PM GMT, Matthias Urlichs wrote:
> Package: aptitude
> Version: 0.8.13-5
> Severity: important
> X-Debbugs-Cc: smurf@smurf.noris.de
> 
> I'm trying to update a rather complex development system from Bookworm to
> Trixie, i.e. through the 64-bit time transition.

Note that upgrading systems with aptitude is not supported; you should follow
the release notes instructions and upgrade your system using

# apt upgrade --without-new-pkgs
# apt full-upgrade

https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#upgradingpackages

And there you can mark multiple packages at a time, as you can in aptitude's
commandline interface by appending <pkg>+ and <pkg>+ respectively, if
need be.

We take great care to work around issues in apt's solver in package
dependencies such that this process works, but other processes are
not tested.

> 
> The machine has three architectures installed, most libraries
> are (historically) not marked as autoinstalled, and I have a bunch
> of self-built packages of various historical state.
> 
> In this sort of situation it's really common for the autoresolver to not
> find a solution. The problem is that attempting to manually resolve the
> transition causes the "immediate dependency resolution" attempt (which
> aptitude unconditionally performs whenever you change a package's state)
> to take arbitrarily long. I'm seeing 30+ seconds *each time I press + or -*,
> and that's on a >2-GHz 8-core workstation with a heap of RAM. Getting from
> 600 to 50 broken packages took me *two days*.
> 
> Thus, I'd like to (urgently) ask you to add a way to *turn this immediate
> resolution thing off*, via some config option.
> 
> The current situation is untenable; updating nontrivial systems to Trixie
> is going to be a *lot* of fun, for some non-empty subset of them, if this
> isn't fixed.
> 
> The change should be backported to Stable, for obvious reasons.

I am no aptitude expert. I am just a naive apt maintainer.

But I don't quite understand what your goal is here. If you don't
resolve again after making a change you don't know what is broken
then, you can only guess.

In any case, isn't this option already there? Going to the aptitude
settings page shows me:

    Option:  aptitude::Auto-Install
    Default: True
    Value:   True

    If this option is enabled, aptitude will use a simple heuristic to
    immediately resolve the dependencies of each package you flag for
    installation.  This is much faster than the built-in dependency
    resolver, but may produce suboptimal results or fail entirely in some
    scenarios.

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

[toc] | [prev] | [next] | [standalone]

#1210267 — Bug#1079710: [Aptitude-devel] Bug#1079710: aptitude: "Immediate dependency resolution" must be optional

[Multipart message — attachments visible in raw view] — view raw

On 26.08.24 19:12, Julian Andres Klode wrote:
> Note that upgrading systems with aptitude is not supported

IMHO updating systems ultimately is the job of dpkg, and unless I'm 
throwing around various force-whatever options it doesn't matter *at 
all* which tool I use to call "dpkg -i", as long as I do it at least 
once per package and in roughly the correct order.

In any case this is just one example of how to get aptitude into a state 
that it can't easily get out of and which exhibits this problem. There 
are others. I've hit this multiple times during my 20 years of using 
Debian with smaller conflict sets, but the time-64 transition is 
annoying enough so I'm finally asking the maintainers to please fix it, 
or at least add a workaround people can live with, as my C++ foo isn't 
up to the task.

I'm not asking for another tool that can do the job better or differently.

> But I don't quite understand what your goal is here.

My goal is to quickly resolve problems manually that aptitude's built-in 
resolver cannot handle because it consistently tries to uninstall gnome 
or wine-i386 when they happen to conflict with my self-built package, 
five library dependency levels down.

That, or it fails to arrive at a solution in less than an hour and/or 
asks me whether I want it to continue. Umpteen times.

The time-64 transition is *difficult*. It replaces 150+ libraries and 
any conflict whatsoever can throw aptitude's resolvers into a tailspin.

>   If you don't
> resolve again after making a change you don't know what is broken
> then, you can only guess.

It's trivial to discover exactly what's broken with aptitude. You press 
"g" and then select "Close".

You can then use the list of packages with unresolved problems (it's 
right at the top) to fix conflicts manually, the way you want to, until 
the "real" resolver is again able to find a possible solution using less 
than 100GB memory and/or less than five weeks' runtime.

If you never ended up in that kind of situation, consider yourself lucky.

> In any case, isn't this option already there?

Unfortunately, no it's not. This setting doesn't change aptitude's 
behavior in this case.

=====

What I want is simple. I want to press "+" or "-" on a specific package 
version, and I want this action to change the intended state of that 
package *and nothing else*. If that results in ten other packages to be 
uninstallable, that's on me.

Debian currently does not have an interactive tool that can do this. 
IMHO it's important to fix this.

There'll always be intractable situations. Package dependency resolution 
is NP-complete after all.

No, using the command line to add hints will not fix this. You want to 
add every single time64 library until apt stumbles on the solution you 
want? be my guest.

-- 
-- Matthias Urlichs

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web