[Pkg-zsh-devel] Bug#962135: Bug#962135: Bug#962135: patch for bugs 962133 and 962135

[Vincent Lefevre]

On 2020-06-04 03:32:49 +0000, Daniel Shahaf wrote:
> Furthermore, I'd rather not remove code just because it's currently
> unused in zsh.git.  The completion system — especially the Type/*
> functions — is an API, not a blackbox.  Does the function proposed for
> removal answer a useful question?  Might third party tools (or even
> people's zshrc files) be using or in the future use that function?  The
> function has already been written (and debugged, etc); how likely is it
> that if we remove it, someone will have to reinvent the wheel?

An issue is that deinstall can mean 2 things:
  1. A package that has been uninstalled but not purged.
  2. A package that is still installed but is selected for
     deinstallation.

and that is not currently documented in _deb_packages_update_deinstalled.
I fear that a tool that uses it is likely to be buggy.

FYI, a case for (1) on one of my machines:

zira:~> dpkg --get-selections | grep deinstall
openntpd                                        deinstall

(and "dpkg -L openntpd" only lists files under /etc and directories
under /var) and for (2) on another machine (where I selected some
packages for upgrade in aptitude, then quit aptitude):

cventin:~> dpkg --get-selections | grep deinstall
libplacebo7:amd64                               deinstall

(and "dpkg -L libplacebo7:amd64" lists all files).

> So, I agree with Axel about the _deb_packages part of the patch.
> 
> As to the _dpkg part of the patch, first of all, it's incomplete:
> it removes the "listfiles" case but not the code that sets that value.

It does not remove "listfiles", but moves it to use "xinstalled"
instead of "installed" (perhaps I forgot to say I fixed that
too). This listfiles command still makes sense for any package
listed by "dpkg --get-selections", even if it has already been
uninstalled (see above on openntpd).

> Once the latter is removed too, the function will then display a single
> asterisk to the user instead of an actual description.  And with _that_
> fixed, there'll still be the issue that, where possible, it's better to
> generate completions than to just tell the user what type of thing they're
> supposed to type in.  Incorrect or incomplete code should, if possible,
> be corrected rather than axed.

I don't understand what you mean.

> I'm not overly familiar with the aptitude/apt/dpkg/dselect hierarchy of
> semantics, but in general, completion should (1) offer everything that
> the command would accept, (2) not offer things the command won't accept.

This is what my patch corrects for the remove, status, listfiles and
list commands.

> That's in descending order of priority: it's usually better to offer too
> much than too little.

Yes, remove, status and listfiles offered too little (only packages
in the install or hold state). On the opposite, list offered too much
(all packages known to apt), but for a package that is not listed by
"dpkg --get-selections", i.e. for which no information is available
for dpkg, I don't see how this can be useful: "dpkg --list foo",
where foo is neither installed, nor uninstalled (but not purged),
just returns an error.

-- 
Vincent Lefèvre <vincent at vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)