Bug#916112: apt-get purge filename.deb not working like expected

[David Kalnischkies]

Hi,

On Fri, Jul 23, 2021 at 09:44:43PM -0500, ng wrote:
> Today I ran 'sudo apt purge ./anything.deb' on a package that WAS NOT
> installed in my system.  And apt's response was to install that package, as
> if I were running 'apt install'.  Except that it was 'apt purge'.
> Funny.

Try: "apt remove awesome+". This will install 'awesome' for you. Just
like a "apt install awesome-" will then remove it again.

The commands "remove/install/purge/…" only provide a default mode
of operation for packages which do not have an explicit action
associated.

Now, for ./anything.deb you can consider two schools of thought:

1. "./anything.deb" clearly means I want to install that package as why
I am going to the trouble of giving an explicit deb file, if I could
just use the name and remove it that way. So this clearly is an explicit
install action regardless of the default mode. ("apt show ./anything.deb"
shows me the info about that version, too, not some candidate as usual).

2. "./anything.deb" is a substitute for the name only, I am using it in
a remove because I just installed it and shell history gives me quick
access to removing it this way. I am expecting it to respect the default
mode (and to be able to explicitly choose a mode ala "./anything.deb+";
and would a "apt purge ./anything_v1.deb" remove an installed anything
v2?).


For better or worse the implementation currently follows the first
school, which can indeed be surprising if you (by not considering what
I just mentioned with default vs. explicit action) think the second is
what is going on as that is how most other software behaves.


I do have some sympathy for both schools, so I am not really sure what
to do about this report here to be honest.

I do lean slightly towards notabug + wontfix though as (even though
highly unlikely in practice) a change of schools would be an interface
break – and it has these weird follow up questions of potentially
allowing ./anything.deb{-,+,=…} as well which makes this not so simple…


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#916112: apt-get purge filename.deb not working like expected

[ng]

apt 2.2.4 (sid)

Bug#916112: apt-get purge filename.deb not working like expected

[ng]

Hello,
Today I ran 'sudo apt purge ./anything.deb' on a package that WAS NOT 
installed in my system.  And apt's response was to install that package, 
as if I were running 'apt install'.  Except that it was 'apt purge'.

Funny.



Have a good day everyone.

Bug#916112: apt-get purge filename.deb not working like expected

[Rhonda D'Vine]

Package: apt
Version: 1.8.0~alpha2
Severity: minor

Dear Maintainer,

 apt-get is great to install packages.  Especially when the package at
hand is locally lying around on the harddisk.  It even resolves
dependencies through its algorithm.

 So far, so good.  What I tried after an "apt-get -y install ./foo.deb"
was an "apt-get -y purge ./foo.deb" to see if it might work too.  It
seemingly is able to figure out the package name, because it gives these
messages:

#v+
Note, selecting 'irssi-build-deps' instead of 
'./irssi-build-deps_1.1.1-1_all.deb'
irssi-build-deps is already the newest version (1.1.1-1).
#v-

 It seemingly is able to figure out the package name from the given
filename, but then seems to have forgotten that a purge was requested,
not an install, which feels a bit weird.

 (Background of this is some auto package building that I want to set up
and need to purge the build-dependencies afterwards again, and the basis
is just the filename that mk-buid-deps created.  Probably not the wisest
approach, and I'll look into other ways to do it, but this made me
stumble upon this. :))

 Hope that helps,
Rhonda