You are not logged in.
Pages: 1
The 64-bit version of wine installs and works fine, but when attempting to install wine32, wine:i386, or wine32:i386 I get the following:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
e2fsprogs : PreDepends: libblkid1 (>= 2.36) but it is not installable
Recommends: e2fsprogs-l10n but it is not going to be installed
init : PreDepends: sysvinit-core but it is not going to be installed or
runit-init but it is not going to be installed
libglib2.0-0 : Depends: libmount1 (>= 2.35.2-7~) but it is not installable
Recommends: shared-mime-info
util-linux : PreDepends: libblkid1 (>= 2.37.2) but it is not installable
PreDepends: libmount1 (>= 2.38) but it is not installable
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
I have the i386 architecture enabled in dpkg. I found a similar thread but the output was completely different. Even using the WineHQ repository I get the same error trying to install those packages.
Offline
This has been written about a number of times. Do not attempt to mix the architectures for WINE. Cannot work (been there, done that).
Offline
Most applications people would want/need in WINE are 32-bit.
Offline
Most applications people would want/need in WINE are 32-bit.
Agree. Which is why WINE is (IMO) deprecated for modern Linux, which almost entirely is powered by 64-bit cpus.
Offline
You're running Ceres - the unstable development version.
One should not be using unstable developer tools if they are not willing+able to debug simple package dependency issues.
Since the two problem packages do currently exist in ceres repository, it's possible the error message is correct - that this was a local issue caused by held packages - but it's also possible it was a temporary issue caused by the fact that Ceres is an unstable development version.
Last edited by boughtonp (2023-07-27 13:51:34)
3.1415P265E589T932E846R64338
Offline
You're running Ceres - the unstable development version.
One should not be using unstable developer tools if they are not willing+able to debug simple package dependency issues.
I migrated from Bookworm which is newer than Chimaera so I would only have the option of Daedulus or Ceres. Testing doesn't get security updates in a timely manner and it doesn't seem Daedulus will become stable soon (despite Bookworm already being here) so I went with Ceres.
Since the two problem packages do currently exist in ceres repository, it's possible the error message is correct - that this was a local issue caused by held packages - but it's also possible it was a temporary issue caused by the fact that Ceres is an unstable development version.
I already unheld the one held package and tried it again, it runs into the same issue.
Offline
Bookworm is now on version 12.1 which is usually taken as a sign that initial bugs have been sorted and sysadmins. can safely upgrade.
So I would expect Daedalus, which exactly the same packages as Bookworm in most cases should equally be ready, apart from the installation isos which are still being tested.
Most security updates appear on Daedalus as soon as they appear on Bookworm since Devuan merges Bookworm packages with the very limited number of 'devuan modified' packages. For example the Zenbleed AMD firmware patch appeared very quickly.
For myself, having upgraded my desk PC from Chimaera to Daedalus a few weeks ago without issue I've now upgraded my two others machines, one a mail server and all seems good.
Offline
I migrated from Bookworm which is newer than Chimaera so I would only have the option of Daedulus or Ceres. Testing doesn't get security updates in a timely manner and it doesn't seem Daedulus will become stable soon (despite Bookworm already being here) so I went with Ceres.
Neither Testing nor Unstable get security updates in a timely manner, but using Unstable is worse than using Testing:
10.1.3. Avoid using the unstable branch
Unless you want to dedicate time to patch packages yourself when a vulnerability arises, you should not use Debian's unstable branch for production-level systems. The main reason for this is that there are no security updates for unstable.
The fact is that some security issues might appear in unstable and not in the stable distribution. This is due to new functionality constantly being added to the applications provided there, as well as new applications being included which might not yet have been thoroughly tested.
At least with Testing, packages have probably had 2-10 days of testing - with Unstable they haven't even had that.
If security matters, your options are:
* use Devuan Stable (Chimaera).
* put up with Debian Stable (Bookworm) until Daedalus is ready.
* learn the necessary skills to manually patch vulnerabilities yourself along with regularly monitoring the status of all software you have installed so that you can apply patches in a timely manner.
That last one involves a lot of time and effort, and is not recommended.
-
I already unheld the one held package and tried it again, it runs into the same issue.
If the issue is the same than the solution is the same.
Apt is stating that the dependency requirements cannot be met and identifies the two packages which cannot be installed.
There are two possibilities: it's on the remote repositories side of things or it's down to changes on your machine.
If it's the former, you can only wait for those responsible to resolve it.
If it's the latter, you need to identify what you have changed to cause the situation.
3.1415P265E589T932E846R64338
Offline
Pages: 1