<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 26.08.24 19:12, Julian Andres Klode
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:20240826190046.GA3356068@debian.org">
      <pre>Note that upgrading systems with aptitude is not supported</pre>
    </blockquote>
    <p>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.</p>
    <p>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.</p>
    <p>I'm not asking for another tool that can do the job better or
      differently.<br>
    </p>
    <blockquote type="cite"
      cite="mid:20240826190046.GA3356068@debian.org">
      <pre>But I don't quite understand what your goal is here.</pre>
    </blockquote>
    <p>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.</p>
    <p>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.</p>
    <p>The time-64 transition is *difficult*. It replaces 150+ libraries
      and any conflict whatsoever can throw aptitude's resolvers into a
      tailspin.<br>
    </p>
    <blockquote type="cite"
      cite="mid:20240826190046.GA3356068@debian.org">
      <pre> If you don't
resolve again after making a change you don't know what is broken
then, you can only guess.
</pre>
    </blockquote>
    <p>It's trivial to discover exactly what's broken with aptitude. You
      press "g" and then select "Close".<br>
    </p>
    <p>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.</p>
    <p>If you never ended up in that kind of situation, consider
      yourself lucky.<br>
    </p>
    <blockquote type="cite"
      cite="mid:20240826190046.GA3356068@debian.org">
      <pre>In any case, isn't this option already there? </pre>
    </blockquote>
    <p>Unfortunately, no it's not. This setting doesn't change
      aptitude's behavior in this case.</p>
    <p>=====<br>
    </p>
    <p>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.</p>
    <p>Debian currently does not have an interactive tool that can do
      this. IMHO it's important to fix this.</p>
    <p>There'll always be intractable situations. Package dependency
      resolution is NP-complete after all.</p>
    <p>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.<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
-- Matthias Urlichs</pre>
  </body>
</html>