Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi,

2016-10-20 02:51 Axel Beckert:

Control: tag -1 + confirmed

Hi Michael,

Michael Biebl wrote:

>> Is this not happening for you?
>
> Seems not, no. But then again, I'm using aptitude most of the time and
> apt only in a few percent of all cases.

It's safe to assume that you have a /var/lib/aptitude/pkgstates.
Can you try install a package via apt which you don't have installed yet
and pulls in other dependencies. Say libclang-4.0-dev (which pulls in
libclang-common-4.0-dev)


Thanks for making up a nice example which is easier for me to test.


+1


$ apt install libclang-4.0-dev
$ apt-mark showauto | grep libclang-common-4.0-dev
libclang-common-4.0-dev
$ aptitude show libclang-common-4.0-dev | grep Auto
Automatically installed: no

I'd be surprised if you get a different result.


There was a missing check for this case, I think that I fixed it now.
Let's hope that I can get it into stable.


Thanks for the report and the clear test case!

--
Manuel A. Fernandez Montecelo 

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Axel Beckert]

Control: tag -1 + confirmed

Hi Michael,

Michael Biebl wrote:
> >> Is this not happening for you?
> > 
> > Seems not, no. But then again, I'm using aptitude most of the time and
> > apt only in a few percent of all cases.
> 
> It's safe to assume that you have a /var/lib/aptitude/pkgstates.
> Can you try install a package via apt which you don't have installed yet
> and pulls in other dependencies. Say libclang-4.0-dev (which pulls in
> libclang-common-4.0-dev)

Thanks for making up a nice example which is easier for me to test.

> $ apt install libclang-4.0-dev
> $ apt-mark showauto | grep libclang-common-4.0-dev
> libclang-common-4.0-dev
> $ aptitude show libclang-common-4.0-dev | grep Auto
> Automatically installed: no
> 
> I'd be surprised if you get a different result.

I indeed get the same result. Can also be seen in my view on that
issue:

# colordiff -u <(aptitude search '~M' | awk '{print $3}') <(apt-mark showauto)
--- /proc/self/fd/112016-10-20 02:45:05.543824588 +0200
+++ /proc/self/fd/122016-10-20 02:45:05.543824588 +0200
@@ -1990,9 +1990,11 @@
 libclang-common-3.6-dev
 libclang-common-3.8-dev
 libclang-common-3.9-dev
+libclang-common-4.0-dev
 libclang1-3.6
 libclang1-3.8
 libclang1-3.9
+libclang1-4.0
 libclass-accessor-chained-perl
 libclass-accessor-classy-perl
 libclass-accessor-grouped-perl
@@ -3645,6 +3647,7 @@
 libllvm3.6v5
 libllvm3.8
 libllvm3.9
+libllvm4.0
 liblmdb0
 liblnk1
 liblo7
@@ -7254,7 +7257,7 @@
 texlive-htmlxml
 texlive-lang-african
 texlive-lang-all
--
+texlive-lang-arabic
 texlive-lang-chinese
 texlive-lang-cjk
 texlive-lang-cyrillic

(I know also know where the latter and already previously present diff
comes from: I have texlive-lang-arabic marked with "forbid-version" in
aptitude due to an RC bug in the most recent version.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Am 20.10.2016 um 02:21 schrieb Axel Beckert:
> According to your description, I'd expect tons of differences.
> 
>> The first time /var/lib/aptitude/pkgstates is created, it inherits the
>> autobit state from the apt db, but after that, any changes apt makes are
>> no longer applied to aptitude.
>>
>> Is this not happening for you?
> 
> Seems not, no. But then again, I'm using aptitude most of the time and
> apt only in a few percent of all cases.

It's safe to assume that you have a /var/lib/aptitude/pkgstates.
Can you try install a package via apt which you don't have installed yet
and pulls in other dependencies. Say libclang-4.0-dev (which pulls in
libclang-common-4.0-dev)

$ apt install libclang-4.0-dev
$ apt-mark showauto | grep libclang-common-4.0-dev
libclang-common-4.0-dev
$ aptitude show libclang-common-4.0-dev | grep Auto
Automatically installed: no

I'd be surprised if you get a different result.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Axel Beckert]

Hi,

Michael Biebl wrote:
> > I somehow doubt that. As I see it, this either this broke only very
> > recently (after the 0.8.3 upload) or it's only happening under some
> > circumstances.
> 
> Just curious, can you reproduce the issue with the steps I outlined?

Haven't tried it yet admittedly.

> From what I can see, once /var/lib/aptitude/pkgstates exists, there is a
> complete disconnect between the autobit state of aptitude and apt.

Not in my case. A Sid amd64 desktop machine with close to 1
packages installed show nearly no difference between apt's and
aptitude's view on the autoinstalled flag:

# colordiff -u <(aptitude search '~M' | awk '{print $3}') <(apt-mark showauto)
--- /proc/self/fd/112016-10-20 02:17:28.622307073 +0200
+++ /proc/self/fd/122016-10-20 02:17:28.622307073 +0200
@@ -7254,7 +7254,7 @@
 texlive-htmlxml
 texlive-lang-african
 texlive-lang-all
--
+texlive-lang-arabic
 texlive-lang-chinese
 texlive-lang-cjk
 texlive-lang-cyrillic

According to your description, I'd expect tons of differences.

> The first time /var/lib/aptitude/pkgstates is created, it inherits the
> autobit state from the apt db, but after that, any changes apt makes are
> no longer applied to aptitude.
> 
> Is this not happening for you?

Seems not, no. But then again, I'm using aptitude most of the time and
apt only in a few percent of all cases.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Am 20.10.2016 um 01:42 schrieb Axel Beckert:
> Hi,
> 
> Michael Biebl wrote:
>> Afaics, once /var/lib/aptitude/pkgstates exists, which it will after any
>> non-trivial use of aptitude, the sync between apt and aptitude is
>> completely broken.
> 
> I somehow doubt that. As I see it, this either this broke only very
> recently (after the 0.8.3 upload) or it's only happening under some
> circumstances.
> 

Just curious, can you reproduce the issue with the steps I outlined?

From what I can see, once /var/lib/aptitude/pkgstates exists, there is a
complete disconnect between the autobit state of aptitude and apt.

The first time /var/lib/aptitude/pkgstates is created, it inherits the
autobit state from the apt db, but after that, any changes apt makes are
no longer applied to aptitude.

Is this not happening for you?



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Am 20.10.2016 um 02:12 schrieb Michael Biebl:
> Am 20.10.2016 um 01:42 schrieb Axel Beckert:
>> Hi,
>>
>> Michael Biebl wrote:
>>> Afaics, once /var/lib/aptitude/pkgstates exists, which it will after any
>>> non-trivial use of aptitude, the sync between apt and aptitude is
>>> completely broken.
>>
>> I somehow doubt that. As I see it, this either this broke only very
>> recently (after the 0.8.3 upload) or it's only happening under some
>> circumstances.
>>
> 
> Just curious, can you reproduce the issue with the steps I outlined?
> 
> From what I can see, once /var/lib/aptitude/pkgstates exists, there is a
> complete disconnect between the autobit state of aptitude and apt.
> 
> The first time /var/lib/aptitude/pkgstates is created, it inherits the
> autobit state from the apt db, but after that, any changes apt makes are
> no longer applied to aptitude.
> 
> Is this not happening for you?

In any case: thanks for your quick replies!


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Axel Beckert]

Hi,

Michael Biebl wrote:
> Afaics, once /var/lib/aptitude/pkgstates exists, which it will after any
> non-trivial use of aptitude, the sync between apt and aptitude is
> completely broken.

I somehow doubt that. As I see it, this either this broke only very
recently (after the 0.8.3 upload) or it's only happening under some
circumstances.

I'll definitely keep an eye on this during daily usage in the next
weeks...

> So I suspect basically everyone will be affected by
> this, who uses both apt and aptitude.

That's my point: I do that not that seldom. And I haven't noticed any
such issues for quite a while.

> But maybe I'm just a bit weird that I use both apt and aptitude at
> the same time :-)

It was not recommended in the past because of known syncing issues.
But they are or at least were gone for quite a while, so I'm surprised
that such an isssue is either still present or surfaced again, maybe
due to some subtle changes in apt.

(The only co-operation "issue" between apt and aptitude I see nowadays
are aptitude's scheduled actions which AFAIK work as intended, but
often confuse users which don't know about them, but use them
unintentionally, usually in aptitude's TUI.)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Am 20.10.2016 um 01:03 schrieb Axel Beckert:
> Hi Michael,
> 
> Michael Biebl wrote:
>> Am 20.10.2016 um 00:44 schrieb Michael Biebl:
>>> So, the complete steps to reproduce the issue:
>>> - create a fresh chroot via debootstrap
>>> - start aptitude in interactive mode, select a random, non-related
>>> package, say netbase, mark it as auto-installed via "M"

fwiw, this step can be replaced by
$ aptitude markauto netbase
or actually any other aptitude action which creates
/var/lib/aptitude/pkgstates, like installing a package via aptitude.

>> At this point, you should have /var/lib/aptitude/pkgstates
>>
>>> - exit aptitude and install the example deb via apt install ./...
>>> - then check the auto state of gobject-introspection. It will now differ
>>> between aptitude and apt.
>>>
>>> The key here is, that you need to have a /var/lib/aptitude/pkgstates
>>
>> Removing that file again:
>>
>> $ aptitude show gobject-introspection | grep Auto
>> Automatically installed: yes
>>
>> Once the pkgstates file exists, aptitude seems to no longer read the
>> autobit state from apt.
> 
> Thanks for all these details! Seems as if there are still some corner
> cases where aptitude doesn't sync the autoinstalled bit properly --
> changing an autoinstalled bit manually without any install/remove
> action seems to such a case according to your description.

Afaics, once /var/lib/aptitude/pkgstates exists, which it will after any
non-trivial use of aptitude, the sync between apt and aptitude is
completely broken. So I suspect basically everyone will be affected by
this, who uses both apt and aptitude. I wouldn't call that a corner
case. But maybe I'm just a bit weird that I use both apt and aptitude at
the same time :-)

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Axel Beckert]

Hi Michael,

Michael Biebl wrote:
> Am 20.10.2016 um 00:44 schrieb Michael Biebl:
> > So, the complete steps to reproduce the issue:
> > - create a fresh chroot via debootstrap
> > - start aptitude in interactive mode, select a random, non-related
> > package, say netbase, mark it as auto-installed via "M"
> 
> At this point, you should have /var/lib/aptitude/pkgstates
> 
> > - exit aptitude and install the example deb via apt install ./...
> > - then check the auto state of gobject-introspection. It will now differ
> > between aptitude and apt.
> > 
> > The key here is, that you need to have a /var/lib/aptitude/pkgstates
> 
> Removing that file again:
> 
> $ aptitude show gobject-introspection | grep Auto
> Automatically installed: yes
> 
> Once the pkgstates file exists, aptitude seems to no longer read the
> autobit state from apt.

Thanks for all these details! Seems as if there are still some corner
cases where aptitude doesn't sync the autoinstalled bit properly --
changing an autoinstalled bit manually without any install/remove
action seems to such a case according to your description.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Am 20.10.2016 um 00:44 schrieb Michael Biebl:
> So, the complete steps to reproduce the issue:
> - create a fresh chroot via debootstrap
> - start aptitude in interactive mode, select a random, non-related
> package, say netbase, mark it as auto-installed via "M"

At this point, you should have /var/lib/aptitude/pkgstates

> - exit aptitude and install the example deb via apt install ./...
> - then check the auto state of gobject-introspection. It will now differ
> between aptitude and apt.
> 
> The key here is, that you need to have a /var/lib/aptitude/pkgstates

Removing that file again:

$ aptitude show gobject-introspection | grep Auto
Automatically installed: yes

Once the pkgstates file exists, aptitude seems to no longer read the
autobit state from apt.

I hope with this information you are able to reproduce the issue now.

Regards,
Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Am 20.10.2016 um 00:23 schrieb Axel Beckert:
> I have a slight suspicion that aptitude and apt might refer to
> different architectures of gobject-introspection in this case (in
> which both might be correct, just not displaying the expected or
> multiple packages).

I don't think this is the problem. I did some further debugging, and
tried with a freshly debootstrapped sid.

Running apt install ./gtk+3.0-build-deps_3.22.1-4_amd64.deb inside that
fresh chroot did lead to

Automatically installed: yes for gobject-introspection.

I went looking what the difference between the chroot and my real system is.
Turns out I have a /var/lib/aptitude/pkgstates. This file/db was created
in the past, when I manually changed the autostate with aptitude
interactive mode.

So, the complete steps to reproduce the issue:
- create a fresh chroot via debootstrap
- start aptitude in interactive mode, select a random, non-related
package, say netbase, mark it as auto-installed via "M"
- exit aptitude and install the example deb via apt install ./...
- then check the auto state of gobject-introspection. It will now differ
between aptitude and apt.

The key here is, that you need to have a /var/lib/aptitude/pkgstates


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Am 20.10.2016 um 00:23 schrieb Axel Beckert:
> Hi Michael,
> 
> Michael Biebl wrote earlier:
>> Architecture: amd64 (x86_64)
>> Foreign Architectures: i386
> 
> Michael Biebl wrote:
>> As an example, after installing the example deb I attached earlier, it
>> pulls in dependencies like gobject-introspection.
>>
>> $ apt-mark showauto  | grep gobject-introspection
>> gobject-introspection
>>
>> $ aptitude show gobject-introspection  | grep Automatically
>> Automatically installed: no
> 
> Can you please send the full output of "aptitude show
> gobject-introspection" and "apt-cache policy gobject-introspection"?
> 
> I have a slight suspicion that aptitude and apt might refer to
> different architectures of gobject-introspection in this case (in
> which both might be correct, just not displaying the expected or
> multiple packages).


$ apt-cache policy gobject-introspection
gobject-introspection:
  Installed: 1.50.0-1
  Candidate: 1.50.0-1
  Version table:
 *** 1.50.0-1 500
500 http://ftp.de.debian.org/debian sid/main amd64 Packages
100 /var/lib/dpkg/status

$ aptitude show gobject-introspection
Package: gobject-introspection   
Version: 1.50.0-1
State: installed
Automatically installed: no
Priority: optional
Section: devel
Maintainer: Debian GNOME Maintainers 

Architecture: amd64
Uncompressed Size: 1448 k
Depends: libc6 (>= 2.14), libffi6 (>= 3.0.4), libgirepository-1.0-1 (= 
1.50.0-1), libglib2.0-0 (>= 2.50.0),
 python3:any, build-essential, python3-mako
Conflicts: gobject-introspection:i386
Description: Generate interface introspection data for GObject libraries
 GObject Introspection is a project for providing machine readable 
introspection data of the API of C libraries.
 This introspection data can be used in several different use cases, for 
example automatic code generation for
 bindings, API verification and documentation generation. 
 
 GObject Introspection contains tools to generate and handle the introspection 
data. 
 
 This package contains tools for extracting introspection data from libraries 
and transforming it to different
 formats.
Homepage: https://wiki.gnome.org/GObjectIntrospection



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Axel Beckert]

Hi Michael,

Michael Biebl wrote earlier:
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386

Michael Biebl wrote:
> As an example, after installing the example deb I attached earlier, it
> pulls in dependencies like gobject-introspection.
> 
> $ apt-mark showauto  | grep gobject-introspection
> gobject-introspection
> 
> $ aptitude show gobject-introspection  | grep Automatically
> Automatically installed: no

Can you please send the full output of "aptitude show
gobject-introspection" and "apt-cache policy gobject-introspection"?

I have a slight suspicion that aptitude and apt might refer to
different architectures of gobject-introspection in this case (in
which both might be correct, just not displaying the expected or
multiple packages).

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Hi

Am 19.10.2016 um 23:48 schrieb Axel Beckert:
> Michael Biebl wrote:
>> So if I install via apt, the auto state is not properly set for
>> aptitude. I have no idea how apt and aptitude interact and if the
>> autobit is something which is supposed to be shared between both?
> 
> It is.
> 
>> Do they access the same database
> 
> Nowadays they do.
> 
>> or is aptitude tracking this information on its own?
> 
> It did it before apt did and hence used its own database in the past.
> But that was fixed IIRC years ago.

Ok, good to know that this should work in theory.

I'm using aptitude 0.8.3-1+b1 here and as I showed in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841347#36

apt and aptitude have a different view regarding the autobit.

I'm happy to provide more information if you tell me what you need.

Regards,
Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#841347: [Aptitude-devel] Bug#841347: packages are not marked as auto "i A" in aptitude

[Axel Beckert]

Hi Michael,

Michael Biebl wrote:
> So if I install via apt, the auto state is not properly set for
> aptitude. I have no idea how apt and aptitude interact and if the
> autobit is something which is supposed to be shared between both?

It is.

> Do they access the same database

Nowadays they do.

> or is aptitude tracking this information on its own?

It did it before apt did and hence used its own database in the past.
But that was fixed IIRC years ago.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Am 19.10.2016 um 23:35 schrieb Michael Biebl:
> apt-mark showauto correctly lists the installed dependencies.
> When running aptitude interactively, it shows the installed dependencies
> as "i" and not "i A" though, which means installed manually and not
> automatically.
> 
> So if I install via apt, the auto state is not properly set for
> aptitude. I have no idea how apt and aptitude interact and if the
> autobit is something which is supposed to be shared between both?
> Do they access the same database or is aptitude tracking this
> information on its own?

As an example, after installing the example deb I attached earlier, it
pulls in dependencies like gobject-introspection.

$ apt-mark showauto  | grep gobject-introspection
gobject-introspection

$ aptitude show gobject-introspection  | grep Automatically
Automatically installed: no


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Thanks for you quick reply, David

Am 19.10.2016 um 21:32 schrieb David Kalnischkies:

> As far as I can see in the reproduce steps apt tools are working as
> expected, it is aptitude which isn't working to your liking, hence
> reassigning as I have no (real) idea about aptitude.
> 
> Given that apt autoremoves the dependencies I guess they are correctly
> marked as automatic on installation (you can check with 'apt-mark
> showauto' to be sure), but somehow aptitude looses the autobit on
> removal. aptitude would usually by default remove the autoremoveable
> packages together with the -build-deps package, wouldn't it?

apt-mark showauto correctly lists the installed dependencies.
When running aptitude interactively, it shows the installed dependencies
as "i" and not "i A" though, which means installed manually and not
automatically.

So if I install via apt, the auto state is not properly set for
aptitude. I have no idea how apt and aptitude interact and if the
autobit is something which is supposed to be shared between both?
Do they access the same database or is aptitude tracking this
information on its own?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#841347: packages are not marked as auto "i A" in aptitude

[David Kalnischkies]

Control: reassign -1 aptitude 0.8.3-1

On Wed, Oct 19, 2016 at 07:04:03PM +0200, Michael Biebl wrote:
> I typically use mk-build-depends -i to install the build dependencies of
> a package.
> 
> Those $foo-build-depends pile up and from time to time I use aptitude
> (in interactive mode) to remove them. But none of the dependencies are
> actually removed then. Afaics, they are all in state "i" instead of
> "i A".
> 
> Interestingly, if I remove the $foo-build-depends package via apt, the
> packages are properly marked for autoremoval.
> 
> Is there some broken interaction between aptitude and apt regarding the
> auto state? I vaguely remember that this worked in the past.
> 
> If you want to reproduce the problem, try the following, with the
> attached deb:
> 
> $ apt file install ./gtk+3.0-build-deps_3.22.1-4_amd64.deb

(the "file" in these commands is bogus)

> [install lots of stuff]
> $ apt remove gtk+3.0-build-deps
> [lists lots of packages as autoinstalled]
> $ apt autoremove
> [removes lots of stuff]
> 
> $ apt file install ./gtk+3.0-build-deps_3.22.1-4_amd64.deb
> [install lots of stuff]
> $ aptitude remove gtk+3.0-build-deps
> [removes gtk+3.0-build-deps]
> $ apt autoremove
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.


As far as I can see in the reproduce steps apt tools are working as
expected, it is aptitude which isn't working to your liking, hence
reassigning as I have no (real) idea about aptitude.

Given that apt autoremoves the dependencies I guess they are correctly
marked as automatic on installation (you can check with 'apt-mark
showauto' to be sure), but somehow aptitude looses the autobit on
removal. aptitude would usually by default remove the autoremoveable
packages together with the -build-deps package, wouldn't it?

I /guess/ that could be intended behavior depending on how you are using
aptitude to remove the package. The introtext mentions interactive mode,
your reproducer would be command mode. Especially in the first one every
keypress can count, so perhaps you want to expand on what you do – but
aptitude people will know better than me what to do (of course, in the
event that this is a libapt regression feel free to hand it back).


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#841347: packages are not marked as auto "i A" in aptitude

[Michael Biebl]

Package: apt
Version: 1.3.1
Severity: normal

Hi!

I typically use mk-build-depends -i to install the build dependencies of
a package.

Those $foo-build-depends pile up and from time to time I use aptitude
(in interactive mode) to remove them. But none of the dependencies are
actually removed then. Afaics, they are all in state "i" instead of
"i A".

Interestingly, if I remove the $foo-build-depends package via apt, the
packages are properly marked for autoremoval.

Is there some broken interaction between aptitude and apt regarding the
auto state? I vaguely remember that this worked in the past.

If you want to reproduce the problem, try the following, with the
attached deb:

$ apt file install ./gtk+3.0-build-deps_3.22.1-4_amd64.deb
[install lots of stuff]
$ apt remove gtk+3.0-build-deps
[lists lots of packages as autoinstalled]
$ apt autoremove
[removes lots of stuff]

$ apt file install ./gtk+3.0-build-deps_3.22.1-4_amd64.deb
[install lots of stuff]
$ aptitude remove gtk+3.0-build-deps
[removes gtk+3.0-build-deps]
$ apt autoremove
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.



Regards,
Michael



-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "true";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.7\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-3\.16\.0-4-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.7\.0-1-amd64$";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "/usr/bin/test -e 
/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && 
/usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call 
--system --dest org.freedesktop.PackageKit --object-path 
/org/freedesktop/PackageKit --timeout 4 --method 
org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo 
> /dev/null";
APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a 
-e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null; fi";
APT::Architectures "";
APT::Architectures:: "amd64";
APT::Architectures:: "i386";
APT::Compressor "";
APT::Compressor::. "";
APT::Compressor::.::Name ".";
APT::Compressor::.::Extension "";
APT::Compressor::.::Binary "";
APT::Compressor::.::Cost