Hi there!
Some time ago I fixed building of the “razorqt” package in some interesting way.
In the cooking log I saw that grep can't understand some options:
grep: unrecognized option '--no-filename'And error is produced by Busybox's grep while Coreutils version of grep was installed as dependency.
Let's think; at this moment we have two versions of the grep at a time:
- /bin/grep from Busybox
- /usr/bin/grep from Coreutils
So I moved Coreutils grep to the same place, /bin/grep; then recook razorqt package, and error is gone.
Now when you install package “grep” it overwrite Busybox's version of the grep, and we have only one grep at a time.
________
It is interesting to see, not touching this problem, but in more common situations:
We always have environmental variable PATH where described colon-separated list of paths where system searches for binaries when we call them without the full path:
/home/tux/.local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/sbin:/usr/local/binExamine list from begin to end, and stop when binary in found.
If we found /usr/bin/grep we use it; otherwise we search next.
If we found /bin/grep we use it; and so on.
(Frankly, I don't know but looks like /bin/grep was hardcoded in the razorqt Makefile).
________
And now the main part.
TazPkg can track files substitutions. Common situation when some package overwrites Busybox's binaries, and you'll get the (more functional) Coreutils versions of the same binaries.
But TazPkg don't track binaries with the same name but located in the different directories!
First example:
Busybox have /bin/gzip binary; it will invoke when you'll use “gzip” in your scripts without the path.
When you install package “gzip” you'll get /usr/bin/gzip. No file overwrite, you still have /bin/gzip, and in addition /usr/bin/gzip. And this /usr/bin/gzip will invoke when you'll use “gzip” in your scripts without the path.
Looks great? Yes, but only when binary invoked without any hardcoded path.
I examined all the binaries from /bin, /usr/bin and so on.
1. There are cross-collisions between Busybox and other packages when other package is invoked instead of Busybox (“good” collisions):
coreutils-file-output-full: /usr/bin/base64
coreutils: /usr/bin/base64
busybox: /bin/base64
coreutils: /usr/bin/cp
busybox: /bin/cp
fatattr: /usr/bin/fatattr
busybox: /bin/fatattr
fbvnc-auth: /usr/bin/fbvnc
fbvnc: /usr/bin/fbvnc
busybox: /bin/fbvnc
gzip: /usr/bin/gunzip
busybox: /bin/gunzip
gzip: /usr/bin/gzip
busybox: /bin/gzip
sysstat: /usr/bin/iostat
busybox: /bin/iostat
ipcalc: /usr/bin/ipcalc
busybox: /bin/ipcalc
kbd: /usr/bin/kbd_mode
busybox: /bin/kbd_mode
coreutils-file-special: /usr/bin/mktemp
busybox: /bin/mktemp
sysstat: /usr/bin/mpstat
busybox: /bin/mpstat
rpm4: /usr/bin/rpm
busybox: /bin/rpm
sed: /usr/bin/sed
busybox: /bin/sed
setserial: /usr/bin/setserial
busybox: /bin/setserial
tunctl: /usr/bin/tunctl
uml-utilities: /usr/bin/tunctl
busybox: /sbin/tunctl
gzip-full: /usr/bin/uncompress
busybox: /bin/uncompress
procps: /usr/bin/watch
busybox: /bin/watch
watchdog: /usr/sbin/watchdog
busybox: /sbin/watchdog
gzip-full: /usr/bin/zcat
busybox: /bin/zcat2. There are cross-collisions between Busybox and other packages when Busybox is invoked instead of other package's binary (“bad” collisions):
busybox: /usr/sbin/httpd
apache: /usr/bin/httpd
busybox: /usr/bin/id
coreutils-context-user: /bin/id
busybox: /sbin/ip
iproute2: /sbin/ip
busybox: /bin/ip
iproute2: /bin/ip
busybox: /sbin/lsmod
kmod: /bin/lsmod
module-init-tools: /bin/lsmod
busybox: /usr/sbin/ntpd
ntp: /usr/bin/ntpd3. There are cross-collisions between other packages (“not clear” collisions):
libee: /usr/sbin/convert
imagemagick: /usr/bin/convert
dhcp-client: /usr/sbin/dhclient
dhcp6-client: /usr/sbin/dhclient
wicd: /usr/bin/dhclient
yp-tools: /usr/bin/domainname
net-tools: /bin/domainname
hylafax: /usr/sbin/faxq
mgetty-voicetools: /usr/bin/faxq
thttpd: /usr/sbin/htpasswd
apache: /usr/bin/htpasswd
dpkg: /usr/sbin/install-info
texinfo: /usr/bin/install-info
nfs-utils: /usr/sbin/nfsiostat
sysstat: /usr/bin/nfsiostat
yp-tools: /usr/bin/nisdomainname
net-tools: /bin/nisdomainname
mgetty: /usr/sbin/sendfax
hylafax: /usr/bin/sendfax
systemd: /usr/bin/udevadm
eudev: /sbin/udevadm
udev: /sbin/udevadm
yp-tools: /usr/bin/ypdomainname
net-tools: /bin/ypdomainname3. There are packages that have binaries with the same name in the different paths(“strange” collisions):
dpkg: /usr/sbin/dpkg-divert
dpkg: /usr/bin/dpkg-divert
dpkg: /usr/sbin/dpkg-statoverride
dpkg: /usr/bin/dpkg-statoverride
cifs-utils: /usr/sbin/mount.cifs
cifs-utils: /sbin/mount.cifs
open-vm-tools: /usr/sbin/mount.vmhgfs
open-vm-tools: /sbin/sbin/mount.vmhgfs (!)
ntop: /usr/bin/ntop
ntop: /bin/ntop
iproute2: /sbin/ss
iproute2: /bin/ss
dpkg: /usr/sbin/update-alternatives
dpkg: /usr/bin/update-alternativesLooks like there's mistake in the “(!)”-marked line.
________
Problems need to be solved. Your opinion?
How would I solved this problem? Change cross-collisions between Busybox and other packages to just collisions that TazPkg can track (with the binary paths like in the Busybox).
PS. I removed the cross-collisions for package “busybox-slish” from above lists. I don't know why it exists, no one package not depends on it. And I don't know why it moves its binaries from /usr/bin to /bin, and from /usr/sbin to /sbin making a mess...
