Bug#923840: bash-completion: not purging all files

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#923840: bash-completion: not purging all files

Boruch Baum
Package: bash-completion
Version: 1:2.8-6
Severity: normal

Dear Maintainer,

Performing an 'apt-get purge bash-completion' does not delete the folder
/usr/share/bash-completion.

Over time, that folder has accumulated what is now cruft, because when
that package updates, it does not remove functions deleted in new
releases; recently upstream has renamed one of their internal helper
functions from 'have' to '_have', and since the cruft files still exist
and are being processed, this results in errors because the old function
name is no longer being found.

An example of this is /usr/share/bash-completion/apt-show-versions,
which at some point was removed from package bash-completion; however,
since the debian packaging has never deleted it, it is now failing that
way.

A second example is /usr/share/bash-completion/insserv.

There are also other files in that folder that are no longer in
upstream, but are not producing that error, such as the script for bzr.

The package expects user-defined or third-party bash-completion scripts
to be located in /etc/bash-completion.d, so there should never be a need
for any non-upstream files in folder /usr/share/bash-completion/completions.

As 'extra-credit', it would be nice if there were an apt hook for this
package that when upstream was removing a script for a command, to
mention that to the user, and prompt to move it to
/etc/bash_completion.d or somewhere else. Another idea would be to just
send apt mail to user with the file along with a message.


-- System Information:
Distributor ID: Devuan
Description: Devuan GNU/Linux 2.0.0 (ascii)
Release: 2.0.0
Codename: ascii
Architecture: x86_64

Kernel: Linux 4.14.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages nnn depends on:
ii  libc6         2.28-5
ii  libncursesw6  6.1+20181013-1
ii  libtinfo6     6.1+20181013-1

nnn recommends no packages.

nnn suggests no packages.

-- no debconf information

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0

Reply | Threaded
Open this post in threaded view
|

Bug#923840: Some additional information

Boruch Baum
Upon manually deleting the directory and re-installing the package, I
see some surprising omissions that I expect are due to third-party
packages installing their own scripts into the
/usr/share/bash-completion/completions folder instead of into
/etc/bash_completion.d/ . Does that need to be separate bug reports
(policy violation) against each of those packages? My list has 159
entries. It's quite possible that there would be more, had I installed
every single package in the debian repositories ...

adb
addpart
apt
apt-file
apt-offline
apt-show-versions
atool
axi-cache
blkdiscard
blkid
blockdev
btrfs
bwrap
bzr
chcpu
chmem
chrt
ctrlaltdel
ddgr-completion.bash
debconf
debconf-show
debget
debian-goodies.pkgnames
debmany
deborphan
debtags
delpart
dhomepage
dmesg
falkon
fallocate
fastboot
fdformat
findfs
findmnt
firecfg
firejail
firemon
flock
fsck
fsck.cramfs
fsck.minix
fsfreeze
fstrim
gapplication
gdbus
getopt
gio
git
gitk
gresource
gsettings
hub
hwclock
insserv
ionice
ipcmk
ipcrm
ipcs
isoquery
isosize
kmod
last
ldattach
libreoffice
logger
loginctl
losetup
lsblk
lscpu
lsipc
lslocks
lslogins
lsmem
lsns
lxc
lxc-attach
lxc-cgroup
lxc-console
lxc-copy
lxc-create
lxc-destroy
lxc-device
lxc-execute
lxc-freeze
lxc-info
lxc-monitor
lxc-snapshot
lxc-start
lxc-stop
lxc-unfreeze
lxc-wait
lynis
mcookie
mdbtools
mesg
mkfs
mkfs.bfs
mkfs.cramfs
mkfs.minix
mkswap
more
mount
mountpoint
namei
nnn-completion.bash
nsenter
openvpn
partx
perf
pivot_root
pkcon
prlimit
pygmentize
qpdf
R
rake
raw
readprofile
redis-cli
renice
resizepart
rev
rtcwake
script
scriptreplay
setarch
setsid
setterm
source-highlight
su
svn
svnadmin
svndumpfilter
svnlook
svnversion
swaplabel
swapoff
swapon
taskset
tc
tig
udisksctl
ufw
umount
unshare
update-initramfs
update-java-alternatives
utmpdump
wall
wdctl
whereis
which-pkg-broke
whiptail
wipefs
wxmaxima
youtube-dl
zathura
zramctl




--
hkp://keys.gnupg.net CA45 09B5 5351 7C11 A9D1 7286 0036 9E45 1595 8BC0

Reply | Threaded
Open this post in threaded view
|

Bug#923840: bash-completion: not purging all files

Gabriel F. T. Gomes-2
In reply to this post by Boruch Baum
Hi, thanks for the report.  I have a few comments, see below...

On Tue, Mar 05 2019, Boruch Baum wrote:
>
> Performing an 'apt-get purge bash-completion' does not delete the folder
> /usr/share/bash-completion.

That's intentional.  Many packages install completion files under
/usr/share/bash-completion/completions, for instance, on my machine,
after purging bash-completion, I get:

  # dpkg -S /usr/share/bash-completion/completions/*
  adb: /usr/share/bash-completion/completions/adb
  util-linux: /usr/share/bash-completion/completions/addpart
  apt: /usr/share/bash-completion/completions/apt
  apt-file: /usr/share/bash-completion/completions/apt-file
  util-linux: /usr/share/bash-completion/completions/blkdiscard
  util-linux: /usr/share/bash-completion/completions/blkid
  util-linux: /usr/share/bash-completion/completions/blkzone
  util-linux: /usr/share/bash-completion/completions/blockdev
  systemd: /usr/share/bash-completion/completions/bootctl
  btrfs-progs: /usr/share/bash-completion/completions/btrfs
  devscripts: /usr/share/bash-completion/completions/bts
  devscripts: /usr/share/bash-completion/completions/build-rdeps
  ...
  (the list goes on and on)

Thus, 'apt-get purge bash-completion' cannot remove
/usr/share/bash-completion.

> Over time, that folder has accumulated what is now cruft, because when
> that package updates, it does not remove functions deleted in new
> releases;

Are you saying that apt-get update bash-completion will not remove files
that were present in version X, but removed in version X+1?  If that's
what you meant, then I need an example of such behavior, because, in my
experience, it does remove them.

> recently upstream has renamed one of their internal helper
> functions from 'have' to '_have', and since the cruft files still exist
> and are being processed, this results in errors because the old function
> name is no longer being found.

Maybe these files are installed by different packages, not
bash-completion

> An example of this is /usr/share/bash-completion/apt-show-versions,
> which at some point was removed from package bash-completion; however,
> since the debian packaging has never deleted it, it is now failing that
> way.

Maybe the output of

  $ dpkg -S /usr/share/bash-completion/completions/apt-show-versions

will tell us where this file comes from.

> A second example is /usr/share/bash-completion/insserv.

Likewise.
 
> There are also other files in that folder that are no longer in
> upstream, but are not producing that error, such as the script for bzr.

Likewise.

Actually, I have already checked this one:

  # dpkg -S /usr/share/bash-completion/completions/bzr
  bzr: /usr/share/bash-completion/completions/bzr

Which means that bash-completion has no power over this file.
 
> The package expects user-defined or third-party bash-completion scripts
> to be located in /etc/bash-completion.d, so there should never be a need
> for any non-upstream files in folder /usr/share/bash-completion/completions.

That's not true nowadays.  I believe that there was a time when all
completion files used to be installed under /etc/bash-completion.d, but
that is not the case anymore.  All completion files should be installed
under /usr/share/bash-completion/completions, even if they are shipped
by other packages, such as bzr.

Notice that bash-completion still looks for completion files under
/etc/bash-completion.d, but that is deprecated and only provided so that
other packages have time to migrate their files.
 
> As 'extra-credit', it would be nice if there were an apt hook for this
> package that when upstream was removing a script for a command, to
> mention that to the user, and prompt to move it to
> /etc/bash_completion.d or somewhere else. Another idea would be to just
> send apt mail to user with the file along with a message.

What are you referring to as upstream?  Upstream bash-completion?

Reply | Threaded
Open this post in threaded view
|

Bug#923840: bash-completion: not purging all files

Boruch Baum
I looked up the debian policy and the linux file system hierarchy
standard, and you're right that it does allow any package to install
anything anywhere to /usr/share as long as it's architecture-agnostic.
That was my misunderstanding when submitting the report: I thought that
the sub-directories under /usr/share were reserved for their
package-name, and third-party contributions would go in /etc.

On 2019-03-09 16:53, Gabriel F. T. Gomes wrote:
> Hi, thanks for the report.  I have a few comments, see below...

--
hkp://keys.gnupg.net
CA45 09B5 5351 7C11 A9D1  7286 0036 9E45 1595 8BC0