[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude

[Vincent Lefevre]

And even in a simple case line cnee:

qaa:~> aptitude install -s cnee
The following packages will be REMOVED:  
  libxnee0{u} 
The following packages will be upgraded:
  cnee{b} 
1 packages upgraded, 0 newly installed, 1 to remove and 263 not upgraded.
Need to get 50.4 kB of archives. After unpacking 324 kB will be freed.
The following packages have unmet dependencies:
 cnee : Depends: libxnee0t64 but it is not going to be installed
The following actions will resolve these dependencies:

 Install the following packages:
1) libxnee0t64 [3.19-9.1 (unstable)]



Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

 Keep the following packages at their current version:
1) cnee [3.19-9 (now, stable, testing)]   
2) libxnee0 [3.19-9 (now, stable, testing)]   



Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

 Remove the following packages:
1) cnee [3.19-9 (now, stable, testing)]



Accept this solution? [Y/n/q/?] n

*** No more solutions available ***

No solutions are found, while with apt:

qaa:~> apt install -s cnee
[...]
The following additional packages will be installed:
  libxnee0t64
Suggested packages:
  xnee-doc
The following packages will be REMOVED:
  libxnee0
The following NEW packages will be installed:
  libxnee0t64
The following packages will be upgraded:
  cnee
1 upgraded, 1 newly installed, 1 to remove and 263 not upgraded.
Inst cnee [3.19-9] (3.19-9.1 Debian:unstable [amd64]) []
Remv libxnee0 [3.19-9] []
Inst libxnee0t64 (3.19-9.1 Debian:unstable [amd64])
Conf cnee (3.19-9.1 Debian:unstable [amd64])
Conf libxnee0t64 (3.19-9.1 Debian:unstable [amd64])

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

___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel

[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude

[Vincent Lefevre via Aptitude-devel]

On 2024-02-28 17:28:51 +0100, Sven Joachim wrote:
> No, in this case it is a problem with aptitude's resolver which
> manifests itself due to the following configuration setting:
> 
> > Aptitude::ProblemResolver::SolutionCost "safety, removals";
> 
> This does cause aptitude to hold apt back by default, rather than remove
> libapt-pkg6.0.  You can press 'n' at the prompt, the next solution
> aptitude then suggests is to upgrade apt.

Well, this is really stupid! aptitude sometimes wants to remove
lots of packages just to avoid the package renames, while apt
proposes a right solution (with some easy help)!

For instance, with apt:

cventin:~> apt install -s gir1.2-atk-1.0 libwine:i386
[...]
libwine:i386 is already the newest version (9.0~repack-4).
libwine:i386 set to manually installed.
The following additional packages will be installed:
  at-spi2-common at-spi2-core gir1.2-atspi-2.0 gir1.2-girepository-2.0-dev
  gobject-introspection gobject-introspection-bin libatk-adaptor
  libatk-bridge2.0-0t64 libatk-bridge2.0-dev libatk1.0-0t64 libatk1.0-dev
  libatspi2.0-0t64 libatspi2.0-dev libgirepository-1.0-dev
  libgirepository1.0-dev libglib2.0-0t64 libglib2.0-0t64:i386 libglib2.0-bin
  libglib2.0-data libglib2.0-dev libglib2.0-dev-bin python3-mako
  python3-markdown python3-markupsafe
Suggested packages:
  libgirepository1.0-doc low-memory-monitor low-memory-monitor:i386
  libglib2.0-doc python-mako-doc python3-beaker python-markdown-doc
The following packages will be REMOVED:
  libatk-bridge2.0-0 libatk1.0-0 libatspi2.0-0 libglib2.0-0 libglib2.0-0:i386
The following NEW packages will be installed:
  gir1.2-girepository-2.0-dev gobject-introspection gobject-introspection-bin
  libatk-bridge2.0-0t64 libatk1.0-0t64 libatspi2.0-0t64
  libgirepository-1.0-dev libgirepository1.0-dev libglib2.0-0t64
  libglib2.0-0t64:i386 python3-mako python3-markdown python3-markupsafe
The following packages will be upgraded:
  at-spi2-common at-spi2-core gir1.2-atk-1.0 gir1.2-atspi-2.0 libatk-adaptor
  libatk-bridge2.0-dev libatk1.0-dev libatspi2.0-dev libglib2.0-bin
  libglib2.0-data libglib2.0-dev libglib2.0-dev-bin
12 upgraded, 13 newly installed, 5 to remove and 263 not upgraded.
[...]

Note that all the removes correspond to package renames.

I had to provide libwine:i386, otherwise apt wanted to remove it.

With aptitude, I need to use 'n' 21 times until I reach the right
solution (with an unmet dependency after that, which can be resolved,
though).

cventin:~> aptitude install -s gir1.2-atk-1.0 libwine:i386
libwine:i386 is already installed at the requested version (9.0~repack-4)
libwine:i386 is already installed at the requested version (9.0~repack-4)
The following packages will be upgraded:
  at-spi2-common gir1.2-atk-1.0{b} 
2 packages upgraded, 0 newly installed, 0 to remove and 273 not upgraded.
Need to get 190 kB of archives. After unpacking 0 B will be used.
The following packages have unmet dependencies:
 libatk1.0-dev : Depends: gir1.2-atk-1.0 (= 2.50.0-1+b1) but 2.51.90-1 is to be 
installed
 gir1.2-atk-1.0 : Depends: libatk1.0-0t64 (>= 2.51.90) but it is not going to 
be installed
The following actions will resolve these dependencies:

 Keep the following packages at their current version:
1) gir1.2-atk-1.0 [2.50.0-1+b1 (now, testing)]



Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

  Remove the following packages: 
1)  libatk-bridge2.0-dev [2.50.0-1+b1 (now, testing)]
2)  libatk1.0-0 [2.50.0-1+b1 (now, testing, unstable)]   
3)  libatk1.0-dev [2.50.0-1+b1 (now, testing)]   
4)  libglib2.0-0 [2.78.4-1 (now, testing, unstable)] 
5)  libglib2.0-0:i386 [2.78.4-1 (now, testing, unstable)]
6)  libgtk-3-dev [3.24.41-1 (now, testing)]  
7)  libgtk2.0-dev [2.24.33-3 (now, testing)] 

  Install the following packages:
8)  libatk1.0-0t64 [2.51.90-1 (unstable)]
9)  libglib2.0-0t64 [2.78.4-2.1 (unstable)]  
10) libglib2.0-0t64:i386 [2.78.4-2.1 (unstable)] 

  Upgrade the following packages:
11) libglib2.0-bin [2.78.4-1 (now, testing) -> 2.78.4-2.1 (unstable)]
12) libglib2.0-dev [2.78.4-1 (now, testing) -> 2.78.4-2.1 (unstable)]
13) libglib2.0-dev-bin [2.78.4-1 (now, testing) -> 2.78.4-2.1 (unstable)]



Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

  Remove the following packages: 
1)  libatk-bridge2.0-dev [2.50.0-1+b1 (now, testing)]
2)  libatk1.0-0 [2.50.0-1+b1 (now, testing, unstable)]   
3)  libatk1.0-dev 

[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude

[Vincent Lefevre]

On 2024-02-29 14:11:41 +0900, Simon Richter wrote:
> Hi,
> 
> On 2/28/24 23:49, Vincent Lefevre wrote:
> 
> > # aptitude install apt
> > The following packages will be upgraded:
> >apt{b} apt-doc
> > 2 packages upgraded, 0 newly installed, 0 to remove and 180 not upgraded.
> > Need to get 1622 kB of archives. After unpacking 0 B will be used.
> > The following packages have unmet dependencies:
> >   apt : Depends: libapt-pkg6.0t64 (>= 2.7.12+nmu1) but it is not going to 
> > be installed
> >   apt-utils : Depends: apt (= 2.7.12) but 2.7.12+nmu1 is to be installed
> > The following actions will resolve these dependencies:
> > 
> >   Keep the following packages at their current version:
> > 1) apt [2.7.12 (now, testing)]
> 
> That is a valid possible resolution. Presumably, if you reject this
> resolution, it will instead propose to upgrade apt-utils, install
> libapt-pkg6.0t64 and remove libapt-pkg6.0.
> 
> Since that is a larger change, the conservative proposal comes first.
> 
> apt-utils has a versioned dependency on apt, which means upgrading
> apt alone (which you requested)

No, this requests to upgrade *all* packages of the same source
(well, at least in the TUI, which I normally use, but there is
the same issue in the TUI).

> breaks another "unrelated" package. There has been some debate that
> resolvers should favour upgrading all binaries that are built from
> the same source together, but that has not been implemented yet, and
> it is unclear if that would have changed anything here.

See above, but in any case...

> > So, I suppose that this is also the case for aptitude: if aptitude
> > cannot upgrade just because of a rename, then this is a problem in
> > the involved packages.
> 
> Note that you haven't requested an "upgrade" (which would likely have
> worked, because it would have switched both apt and apt-utils to the new
> version, and the remaining involved packages were automatically installed as
> dependencies of the packages being upgraded).

This doesn't work with an upgrade either:

qaa:~> aptitude upgrade -s
Resolving dependencies...
The following NEW packages will be installed:
  libatrildocument3t64{a} libatrilview3t64{a} libboost-chrono1.83.0t64{a} 
  libcupsfilters1t64{a} libevdocument3-4t64{a} libevemu3t64{a} 
  libevview3-3t64{a} libfontembed1t64{a} libgxps2t64{a} 
  libtss2-mu-4.0.1-0t64{a} 
The following packages will be REMOVED:
  libatrildocument3{u} libatrilview3{u} libboost-chrono1.83.0{u} 
  libcupsfilters1{u} libevdocument3-4{u} libevemu3{u} libevview3-3{u} 
  libfontembed1{u} libgxps2{u} libtss2-mu0{u} 
The following packages will be upgraded:
  apt-doc at-spi2-common atril atril-common cups-browsed cups-filters 
  cups-filters-core-drivers evemu-tools evince evince-common 
  evolution-data-server-common gir1.2-pango-1.0 glib-networking 
  glib-networking-common glib-networking-services glibc-doc-reference 
  gnome-calendar gnome-remote-desktop gnome-settings-daemon 
  gnome-settings-daemon-common gnome-text-editor libboost-atomic1.83-dev 
  libboost-atomic1.83.0 libboost-chrono1.83-dev libboost-date-time1.83-dev 
  libboost-date-time1.83.0 libboost-filesystem1.83-dev 
  libboost-filesystem1.83.0 libboost-iostreams1.83.0 libboost-locale1.83.0 
  libboost-program-options1.83-dev libboost-program-options1.83.0 
  libboost-regex1.83-dev libboost-regex1.83.0 
  libboost-serialization1.83-dev libboost-serialization1.83.0 
  libboost-system1.83-dev libboost-system1.83.0 libboost-thread1.83-dev 
  libboost-thread1.83.0 libboost1.83-dev libglib2.0-data liblzma-dev 
  liblzma5 libnss-myhostname libnss-systemd libpam-runtime libpam-systemd 
  libpango-1.0-0 libpango1.0-dev libpangocairo-1.0-0 libpangoft2-1.0-0 
  libpangoxft-1.0-0 libsystemd-shared libsystemd0 libtss2-esys-3.0.2-0 
  libtss2-rc0 libtss2-sys1 libtss2-tcti-cmd0 libtss2-tcti-device0 
  libtss2-tcti-libtpms0 libtss2-tcti-mssim0 libtss2-tcti-spi-helper0 
  libtss2-tcti-swtpm0 libtss2-tctildr0 libudev1 pango1.0-tools sa-compile 
  spamassassin spamc spamd systemd systemd-dev systemd-sysv 
  systemd-timesyncd udev xz-utils 
The following packages are RECOMMENDED but will NOT be installed:
  evolution-data-server 
77 packages upgraded, 10 newly installed, 10 to remove and 22 not upgraded.
Need to get 37.2 MB/43.6 MB of archives. After unpacking 728 kB will be used.

apt-doc is proposed for upgrade, but not apt.

What's strange is that it appears to work for some packages, e.g.
libatrildocument3 replaced by libatrildocument3t64, but not for
other ones (e.g. libapt-pkg6.0 replaced by libapt-pkg6.0t64).

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

___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel

[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude

[Simon Richter]

Hi,

On 2/28/24 23:49, Vincent Lefevre wrote:


# aptitude install apt
The following packages will be upgraded:
   apt{b} apt-doc
2 packages upgraded, 0 newly installed, 0 to remove and 180 not upgraded.
Need to get 1622 kB of archives. After unpacking 0 B will be used.
The following packages have unmet dependencies:
  apt : Depends: libapt-pkg6.0t64 (>= 2.7.12+nmu1) but it is not going to be 
installed
  apt-utils : Depends: apt (= 2.7.12) but 2.7.12+nmu1 is to be installed
The following actions will resolve these dependencies:

  Keep the following packages at their current version:
1) apt [2.7.12 (now, testing)]


That is a valid possible resolution. Presumably, if you reject this 
resolution, it will instead propose to upgrade apt-utils, install 
libapt-pkg6.0t64 and remove libapt-pkg6.0.


Since that is a larger change, the conservative proposal comes first.

apt-utils has a versioned dependency on apt, which means upgrading apt 
alone (which you requested) breaks another "unrelated" package. There 
has been some debate that resolvers should favour upgrading all binaries 
that are built from the same source together, but that has not been 
implemented yet, and it is unclear if that would have changed anything here.



So, I suppose that this is also the case for aptitude: if aptitude
cannot upgrade just because of a rename, then this is a problem in
the involved packages.


Note that you haven't requested an "upgrade" (which would likely have 
worked, because it would have switched both apt and apt-utils to the new 
version, and the remaining involved packages were automatically 
installed as dependencies of the packages being upgraded).


   Simon

___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel

[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude

[Vincent Lefevre]

On 2024-02-28 18:32:20 +0100, Vincent Lefevre wrote:
> OK, but it appears that now, there are *many* other packages in
> a similar situation, and sometimes, aptitude wants to remove a
> potentially important package (see below). The resolution should
> be automatic in case of package rename.
> 
> # aptitude install libglib2.0-dev

I would add that in this apparently more complex case, apt
(e.g. "apt install libglib2.0-dev" or "apt dist-upgrade") is
far worse than aptitude as it wants to remove wine32:i386.

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

___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel

[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude

[Wesley Schwengle]

Hi Vincent,

I'm having similar problems, but I think it may be related to the t64 
upgrade that is going on. I get the following when doing aptitude 
full-upgrade:


13 packages upgraded, 0 newly installed, 4 to remove and 0 not upgraded.
Need to get 5759 kB of archives. After unpacking 1241 kB will be freed.
The following packages have unmet dependencies:
 openvpn : Depends: libpam0t64 (>= 0.99.7.1) but it is not going to be 
installed
 libglib2.0-dev-bin : Depends: libglib2.0-0 (= 2.78.4-2) but 2.78.4-1 
is installed
 evince : Depends: libevdocument3-4t64 (= 45.0-2) but it is not going 
to be installed
  Depends: libevview3-3t64 (= 45.0-2) but it is not going to be 
installed
 apt : Depends: libapt-pkg6.0t64 (>= 2.7.12+nmu1) but it is not going 
to be installed
 libglib2.0-bin : Depends: libglib2.0-0 (= 2.78.4-2) but 2.78.4-1 is 
installed
 libglib2.0-dev : Depends: libglib2.0-0t64 (= 2.78.4-2) but it is not 
going to be installed
 libpam-modules : PreDepends: libdb5.3t64 but it is not going to be 
installed
  PreDepends: libpam0t64 (>= 1.4.1) but it is not going 
to be installed
 libdb5.3-dev : Depends: libdb5.3t64 (= 5.3.28+dfsg2-4.1) but it is not 
going to be installed
Depends: libdb5.3 (= 5.3.28+dfsg2-4.1) but 
5.3.28+dfsg2-4+b1 is installed
 gir1.2-atk-1.0 : Depends: libatk1.0-0t64 (>= 2.49.90) but it is not 
going to be installed
 libpam-modules-bin : Depends: libpam0t64 (>= 0.99.7.1) but it is not 
going to be installed
 xmlsec1 : Depends: libxmlsec1t64 (>= 1.2.35) but it is not going to be 
installed
   Depends: libxmlsec1t64-openssl (>= 1.2.31) but it is not 
going to be installed

 db5.3-util : Depends: libdb5.3t64 but it is not going to be installed
  Depends: libdb5.3 (= 5.3.28+dfsg2-4.1) but 
5.3.28+dfsg2-4+b1 is installed
 apt-utils : Depends: libapt-pkg6.0t64 (>= 2.7.12+nmu1) but it is not 
going to be installed

The following actions will resolve these dependencies:

  Remove the following packages:
1)  libapt-pkg6.0 [2.7.12 (now, testing, unstable)]
2)  libatk1.0-0 [2.50.0-1+b1 (now, testing, unstable)]
3)  libdb5.3 [5.3.28+dfsg2-4+b1 (now, testing, unstable)]
4)  libevdocument3-4 [45.0-1+b1 (now, testing, unstable)]
5)  libglib2.0-0 [2.78.4-1 (now, testing, unstable)]
6)  libglib2.0-0:i386 [2.78.4-1 (now, testing, unstable)]
7)  libpam0g [1.5.2-9.1+b1 (now, testing, unstable)]
8)  libxmlsec1 [1.2.38-1+b1 (now, testing, unstable)]

  Install the following packages:
9)  libapt-pkg6.0t64 [2.7.12+nmu1 (unstable)]
10) libatk1.0-0t64 [2.50.0-1.1 (unstable)]
11) libdb5.3t64 [5.3.28+dfsg2-4.1 (unstable)]
12) libevdocument3-4t64 [45.0-2 (unstable)]
13) libevview3-3t64 [45.0-2 (unstable)]
14) libglib2.0-0t64 [2.78.4-2 (unstable)]
15) libglib2.0-0t64:i386 [2.78.4-2 (unstable)]
16) libpam0t64 [1.5.3-4 (unstable)]
17) libxmlsec1t64 [1.2.39-4 (unstable)]
18) libxmlsec1t64-openssl [1.2.39-4 (unstable)]

  Downgrade the following packages:
19) libgspell-1-2 [1.12.2-1+b1 (now, testing, unstable) -> 1.8.4-1 
(oldstable)]
20) libgspell-1-common [1.12.2-1 (now, testing, unstable) -> 1.8.4-1 
(oldstable)]


It starts with the following resolution:
The following actions will resolve these dependencies:

  Remove the following packages:
1)  libapt-pkg6.0 [2.7.12 (now, testing, unstable)]
2)  libatk1.0-0 [2.50.0-1+b1 (now, testing, unstable)]
3)  libdb5.3 [5.3.28+dfsg2-4+b1 (now, testing, unstable)]
4)  libevdocument3-4 [45.0-1+b1 (now, testing, unstable)]
5)  libglib2.0-0 [2.78.4-1 (now, testing, unstable)]
6)  libglib2.0-0:i386 [2.78.4-1 (now, testing, unstable)]
7)  libpam0g [1.5.2-9.1+b1 (now, testing, unstable)]
8)  libxmlsec1 [1.2.38-1+b1 (now, testing, unstable)]

  Install the following packages:
9)  libapt-pkg6.0t64 [2.7.12+nmu1 (unstable)]
10) libatk1.0-0t64 [2.50.0-1.1 (unstable)]
11) libdb5.3t64 [5.3.28+dfsg2-4.1 (unstable)]
12) libevdocument3-4t64 [45.0-2 (unstable)]
13) libevview3-3t64 [45.0-2 (unstable)]
14) libglib2.0-0t64 [2.78.4-2 (unstable)]
15) libglib2.0-0t64:i386 [2.78.4-2 (unstable)]
16) libpam0t64 [1.5.3-4 (unstable)]
17) libxmlsec1t64 [1.2.39-4 (unstable)]
18) libxmlsec1t64-openssl [1.2.39-4 (unstable)]

  Downgrade the following packages:
19) libgspell-1-2 [1.12.2-1+b1 (now, testing, unstable) -> 1.8.4-1 
(oldstable)]
20) libgspell-1-common [1.12.2-1 (now, testing, unstable) -> 1.8.4-1 
(oldstable)]


After a couple of "No's" to the solutions aptitude gives me I get at 
this stage:


The following actions will resolve these dependencies:

  Remove the following packages:
1)  libapt-pkg6.0 [2.7.12 (now, testing, unstable)]
2)  libatk1.0-0 [2.50.0-1+b1 (now, testing, unstable)]
3)  libdb5.3 [5.3.28+dfsg2-4+b1 (now, testing, unstable)]
4)  libevdocument3-4 [45.0-1+b1 (now, testing, unstable)]
5)  libglib2.0-0 [2.78.4-1 

[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude

[Vincent Lefevre]

On 2024-02-28 17:28:51 +0100, Sven Joachim wrote:
> On 2024-02-28 15:49 +0100, Vincent Lefevre wrote:
> > So, I suppose that this is also the case for aptitude: if aptitude
> > cannot upgrade just because of a rename, then this is a problem in
> > the involved packages.
> 
> No, in this case it is a problem with aptitude's resolver which
> manifests itself due to the following configuration setting:
> 
> > Aptitude::ProblemResolver::SolutionCost "safety, removals";
> 
> This does cause aptitude to hold apt back by default, rather than
> remove libapt-pkg6.0.

The goal of this configuration setting (which was given in the
debian-user list in the past) was to prevent aptitude from removing
packages with no replacement (e.g. firefox, libreoffice, and so on).
Here, the libapt-pkg6.0 package has been renamed. I hope that you
can understand that this is a completely different situation.

> You can press 'n' at the prompt, the next solution aptitude then
> suggests is to upgrade apt.

OK, but it appears that now, there are *many* other packages in
a similar situation, and sometimes, aptitude wants to remove a
potentially important package (see below). The resolution should
be automatic in case of package rename.

# aptitude install libglib2.0-dev
The following packages will be REMOVED:
  libglib2.0-dev-bin{u}
The following packages will be upgraded:
  libglib2.0-data libglib2.0-dev{b}
2 packages upgraded, 0 newly installed, 1 to remove and 61 not upgraded.
Need to get 2865 kB of archives. After unpacking 716 kB will be freed.
The following packages have unmet dependencies:
 libglib2.0-dev : Depends: libglib2.0-0t64 (= 2.78.4-2) but it is not going to 
be installed
  Depends: libglib2.0-bin (= 2.78.4-2) but 2.78.4-1 is 
installed and it is kept back
  Depends: libglib2.0-dev-bin (= 2.78.4-2) but it is not going 
to be installed
The following actions will resolve these dependencies:

 Keep the following packages at their current version:
1) libglib2.0-dev [2.78.4-1 (now, testing)]
2) libglib2.0-dev-bin [2.78.4-1 (now, testing)]

Accept this solution? [Y/n/q/?] n
The following actions will resolve these dependencies:

 Remove the following packages:
1) libglib2.0-0 [2.78.4-1 (now, testing, unstable)]
2) libglib2.0-0:i386 [2.78.4-1 (now, testing, unstable)]
3) libglib2.0-bin [2.78.4-1 (now, testing)]

 Install the following packages:
4) libglib2.0-0t64 [2.78.4-2 (unstable)]
5) libglib2.0-0t64:i386 [2.78.4-2 (unstable)]
6) libglib2.0-bin:i386 [2.78.4-2 (unstable)]

 Upgrade the following packages:
7) libglib2.0-dev-bin [2.78.4-1 (now, testing) -> 2.78.4-2 (unstable)]

AFAIK, replacing libglib2.0-bin by libglib2.0-bin:i386 is not
equivalent.

With an explicit package list, aptitude immediately gives an
acceptable solution:

$ aptitude install -s libglib2.0-dev libglib2.0-bin libglib2.0-dev-bin 
libglib2.0-0t64 libglib2.0-0t64:i386
The following NEW packages will be installed:
  libglib2.0-0t64 libglib2.0-0t64:i386 
The following packages will be REMOVED:
  libglib2.0-0{a} libglib2.0-0:i386{a} 
The following packages will be upgraded:
  libglib2.0-bin libglib2.0-data libglib2.0-dev libglib2.0-dev-bin 

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

___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel

[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude

[Sven Joachim via Aptitude-devel]

Control: severity -1 normal

On 2024-02-28 15:49 +0100, Vincent Lefevre wrote:

> Source: apt
> Version: 2.7.12+nmu1
> Severity: serious
>
> While there are no upgrade issues with apt itself (according
> to "apt install -s apt"), aptitude does not want to upgrade
> apt automatically, while this just appears to be a package
> rename:
>
> # aptitude install apt
> The following packages will be upgraded:
>   apt{b} apt-doc
> 2 packages upgraded, 0 newly installed, 0 to remove and 180 not upgraded.
> Need to get 1622 kB of archives. After unpacking 0 B will be used.
> The following packages have unmet dependencies:
>  apt : Depends: libapt-pkg6.0t64 (>= 2.7.12+nmu1) but it is not going to be 
> installed
>  apt-utils : Depends: apt (= 2.7.12) but 2.7.12+nmu1 is to be installed
> The following actions will resolve these dependencies:
>
>  Keep the following packages at their current version:
> 1) apt [2.7.12 (now, testing)]
>
> I don't know whether this is actually an issue with aptitude, but at
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059068#15
>
> David Kalnischkies says:
> | You should really know this by now as that isn't your first report, but
> | okay: Upgrade problems are NEVER a problem to be solved in apt,
> | they are ALWAYS a problem in the involved packages. NO EXCEPTIONS.
>
> So, I suppose that this is also the case for aptitude: if aptitude
> cannot upgrade just because of a rename, then this is a problem in
> the involved packages.

No, in this case it is a problem with aptitude's resolver which
manifests itself due to the following configuration setting:

> Aptitude::ProblemResolver::SolutionCost "safety, removals";

This does cause aptitude to hold apt back by default, rather than remove
libapt-pkg6.0.  You can press 'n' at the prompt, the next solution
aptitude then suggests is to upgrade apt.

Cheers,
   Sven

___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel

[Aptitude-devel] Bug#1064969: apt: can't upgrade with aptitude

[Vincent Lefevre via Aptitude-devel]

On 2024-02-28 15:56:56 +0100, Julian Andres Klode wrote:
> aptitude is not our chosen tool for distribution upgrades, as such
> failures there are not release critical for the packages. So while
> this is release critical for aptitude, it's a wishlist bug for apt
> that probably would end up being closed.
> 
> I do believe the correct syntax for aptitude would be to use
> 
> aptitude upgrade apt
> 
> though

OK, though this is much slower. But still, apt is not upgraded
with this solution (and there is no way to choose another action
manually):

# aptitude upgrade apt
Resolving dependencies...
The following packages have been kept back:
  apt
No packages will be installed, upgraded, or removed.
0 packages upgraded, 0 newly installed, 0 to remove and 182 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.

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

___
Aptitude-devel mailing list
Aptitude-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/aptitude-devel