> Preparing to unpack .../15-libubootenv-tool_0.1-1_amd64.deb ... > Unpacking libubootenv-tool (0.1-1) ... > dpkg: error processing archive > /tmp/apt-dpkg-install-S5V5yb/15-libubootenv-tool_0.1-1_amd64.deb (--unpack > ): > trying to overwrite '/usr/bin/fw_printenv', which is also in package > u-boot-tools 2019.01+dfsg-7 > > Since the packages are both u-boot related, the new program might have > the same functionality as the existing one and hence using > update-alternatives for the two variants maybe an option. ... > libubootenv (0.1-2) unstable; urgency=medium > . > * Add u-boot-tools Conflicts of libubootenv-tool (Closes: #939598)
This seems like a rather sub-optimal solution to the problem; now it's impossible to install u-boot-tools at the same time, which has other functionality as well. There are also packages that depend or recommend on u-boot-tools that won't be able to be installed or may have reduced functionality when libubootenv-tool is installed. Many of these packages would seem quite reasonable to have installed with both libubootenv-tool and u-boot-tools installed at the same time, such as u-boot-sunxi... Is there anything in the libubootenv's fw_printenv and fw_setenv implementations that's significantly different from u-boot-tools? Couldn't libubootenv-tool depend on u-boot-tools instead of conflicting with it? Or would it make sense for u-boot-tools to depend on libubootenv-tool instead? Is this likely to be merged in upstream u-boot at some point? Alternately, the original suggestion of using the alternatives system would at least allow both packages to coexist at the same time, at the cost of some additional complication in both packages maintainer scripts. live well, vagrant
signature.asc
Description: PGP signature
