The following packages have unmet dependencies:
duplicati: Depends: libicu but it is not installable or
libicu74 but it is not installable or
libicu72 but it is not installable or
libicu71 but it is not installable or
libicu70 but it is not installable or
libicu69 but it is not installable or
libicu68 but it is not installable or
libicu67 but it is not installable or
libicu66 but it is not installable or
libicu65 but it is not installable or
libicu63 but it is not installable or
libicu60 but it is not installable or
libicu57 but it is not installable or
libicu55 but it is not installable or
libicu52 but it is not installable
I still have not figure out why Debian insists on giving each libicu package a new name, or why they do not provide a libicu-any package. If someone knows how to be future proof, let me know.
As you can see from the list, what we are doing now is just listing all the versions we know exist, and let the package manager choose one. But as new packages are created, the package breaks.
Unfortunately, the naming is not always incremental, so it is hard to support future packages.
In any case, you can ignore it, as you most likely have some version of libicu installed already.
Are there any logs? Are you running Duplicati as a service?
If running as a service, try:
sudo journalctl --unit=duplicati | less
If you are running as a desktop application, try running it in a shell with no arguments:
I ran apt-rdepends --reverse for my system’s favorite libicu to see what can get it in.
icu-devtools seems tiny and has dependencies on likely things, but also system’s libicu.
Although it’s meant for development use, it doesn’t bring in libicu-dev. It goes other way.
ICU Binary Compatibility talks about the kind of issues we might be inviting by assuming everything’s the same, but we’re already inviting that, and might also be with rpm design.
.NET globalization and ICU would be worth reading through. Other ways out may include letting Linux .NET “load the highest installed version of the ICU library from the system”, build in an App-local ICU (may add quite a few MB), or use Globalization Invariant Mode.
EDIT 1:
The icu-devtools method does install tiny (average below 50 KB) binaries and man pages which most users will probably never notice or use, so it’s not entirely odd-side-effect free.
changelog looks pretty incremental to me, but it may depend on what one happens to get, meaning some were possibly quite transitory, yet some people might have those releases.
Further research by somebody (probably not me) could look at Microsoft’s .deb releases:
Whereas things like the distro’s version come with a dependency on distro’s libicu, what is generic package from Microsoft doing for a libicu dependency choice? Or did they omit it?
It might be the least annoying way. I looked at libicu-dev but that seems to pull in lots of unwanted stuff.
This is something that should be handled by .NET
As a developer I would love that but I think most people prefer to have their locale supported unfortunately.
I checked the .NET SDK some time ago and it looks like they are doing the same as Duplicati: make a long list of all the versions known at the time of build.
but I think most people prefer to have their locale supported unfortunately.