Hi! On Wed, 2019-11-20 at 22:59:04 +0000, Alejandro Del Castillo wrote: > I am the current maintainer of opkg, dpkg's little brother used mainly > for embedded systems.
Ah, thanks for getting in touch! :) > Opkg uses dpkg control file syntax, and follows > debian policy (for the most part). Recently, a bug [1] was opened > against opkg regarding symlinks. Basically, debian policy states that > symlinks should be followed, when installing files. But, empirically, I > don't see that: > > (bb) adelcast@delcastillo2 ~/dpkg $ tree a_1.0 > a_1.0 > ├── DEBIAN > │ └── control > ├── myfile > └── tmp > ├── lib > └── lib64 -> lib/ > > 4 directories, 2 files > (bb) adelcast@delcastillo2 ~/dpkg $ tree b_1.0 > b_1.0 > ├── DEBIAN > │ └── control > ├── myfile2 > └── tmp > └── lib64 > └── otherfile > > (bb) adelcast@delcastillo2 ~/dpkg $ sudo dpkg -i a_1.0.deb > Selecting previously unselected package a. > (Reading database ... 620831 files and directories currently installed.) > Preparing to unpack a_1.0.deb ... > Unpacking a (1.0) ... > Setting up a (1.0) ... > (bb) adelcast@delcastillo2 ~/dpkg $ sudo dpkg -i b_1.0.deb > Selecting previously unselected package b. > (Reading database ... 620834 files and directories currently installed.) > Preparing to unpack b_1.0.deb ... > Unpacking b (1.0) ... > dpkg: error processing archive b_1.0.deb (--install): > trying to overwrite '/tmp/lib64', which is also in package a 1.0 > Errors were encountered while processing: > b_1.0.deb > > Can someone clarify why dpkg is behaving this way? Or am I > misinterpreting Debian standards? This is supposed to work, as exemplified by the following functional test case: https://git.dpkg.org/cgit/dpkg/dpkg-tests.git/tree/t-symlink-dir Are you sure the contents of these packages are what's expected? «dpkg-deb -c» would be more telling instead of tree on the unpacked directory. Or perhaps the pathname on disk was neither a directory nor a symlink? Otherwise I guess placing the exact test packages somewhere might help, or you could check with «dpkg --debug=111». Thanks, Guillem
