SliTaz Forum

lexeii

Administrator

Registered: 2012-03-21

Posts: 1,853

Cross-collisions

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:

[c]grep: unrecognized option '--no-filename'[/c]
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:

[c]/home/tux/.local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/sbin:/usr/local/bin[/c]
Examine 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 [c]/bin/gzip[/c] binary; it will invoke when you'll use “gzip” in your scripts without the path.

When you install package “gzip” you'll get [c]/usr/bin/gzip[/c]. No file overwrite, you still have [c]/bin/gzip[/c], and in addition [c]/usr/bin/gzip[/c]. And this [c]/usr/bin/gzip[/c] 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 [c]/bin[/c], [c]/usr/bin[/c] and so on.

1. There are cross-collisions between Busybox and other packages when other package is invoked instead of Busybox (“good” collisions):

[c]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/zcat[/c]
2. There are cross-collisions between Busybox and other packages when Busybox is invoked instead of other package's binary (“bad” collisions):

[c]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/ntpd[/c]
3. There are cross-collisions between other packages (“not clear” collisions):

[c]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/ypdomainname[/c]
3. There are packages that have binaries with the same name in the different paths(“strange” collisions):

[c]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-alternatives[/c]
Looks 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...