Hi Vagrant, On 21/09/19 23:49, Vagrant Cascadian wrote: >> 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...
Right, but it looks like that u-boot-tools contains tools with different meaning that could be addressed with different packages. For example, tools like "netconsole" is missing. The package in libubootenv exposes the "envtools" from U-Boot, that is just the tool to modify the environment. > > Is there anything in the libubootenv's fw_printenv and fw_setenv > implementations that's significantly different from u-boot-tools? >From the user point of view, they are thought to be fully compatible. The syntax for the tool is the same as the original tools to avoid breakages in already implemented script. Anyway, the most important difference (at least for Debian) is the tools are hardware unaware. In fact, the original u-boot-tools must be compiled with the same machine (_defconfig) of the bootloader because the environment is statically linked to the binary. This is a severe issue if a board boots with the "default" environment, that is the environment linked together with the bootloader. The original fw_setenv tool is built just one machine: fw_setenv can brick the target because it cannot know the environment because it was not written to the flash and it is only present in the U-Boot binary. There is no way to instruct the original tool for this. With libubootenv, the environment is read from a file and the same binary can be used on different targets without exceptions. The original discussion about this topic was in this old thread on U-Boot's ML: http://u-boot.10912.n7.nabble.com/SWUpdate-U-Boot-environment-library-dependency-td340530.html Apart of this, libubootenv just addresses "envtools" from U-Boot, while u-boot-tools contains tools for different purposes: image generation (mkimage and friends), environment. My logical way to do is to split u-boot-tools in several sub-packages that won't conflict. This is the solution in OE, too, where a u-boot-mkimage package contains the image generation tool and u-boot-fw-utils contains the envtools. In OE libubootenv is set as replacement for u-boot-fw-utils (with PROVIDES) and there is no conflict. > > Couldn't libubootenv-tool depend on u-boot-tools instead of conflicting > with it? Depend ? No. > Or would it make sense for u-boot-tools to depend on > libubootenv-tool instead? Mmhh.. I do not know. u-boot-tools should not install fw_setenv / fw_printenv is libubootenv is already installed. > Is this likely to be merged in upstream u-boot > at some point? No. libubootenv is also thought to remove some limitations due to the U-Boot build environment. U-Boot cannot use standard library as they are, so code from libraries (libz, openssl, and so on..) is copied from the original library into U-Boot. If this is required for the bootloader that is an independent binary not linked with anything, it is a sub-optimal solution for a User Space tool: libubootenv is simply linked against the required libraries. > > 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. Best regards, Stefano -- ===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de =====================================================================
