I was able to narrow it down to one critical package: libc6-i386...
Back to top

Exactly, except for the idea that debian is trying to avoid clutter, in fact, most debian decisions over the past years have resulted in default clutter creation, just look at what their kde/gnome metapackages install, which is why smxi selects the actual packages you need when you install those desktops via smxi. The other big one is debian's bad decision to make install recommends default for apt, and if any single thing is going to clutter your system, it's installing totally useless recommends every time you install a package. That's why smxi/sgfxi force no recommends always on all package install actions.

So no, the underlying idea was NOT to avoid clutter, it was something else, as I suggested, this reeks of ubuntu, but I can't prove it. Ubuntu has grown fond of introducing then dumping ideas and methods release to release, and that's one reason I don't use ubuntu.

What bothers me is the total failure to provide the information neeeded, at least, somewhere, and the totally inane pretense that multiarch, which ia32-libs already was, somehow replaces that list of default packages that most systems will need. In a sense, you can tell they know inside that this was a dumb decision done for dumb reasons because of the response you get when you ask the question. And the totally absurd documentation.

I've come across another really silly documentation thing like this recently, not in debian, this one was in arch/fedora, where 'runlevel' command has been removed, at least in arch, then the wikis all say to do this command:
systemctl list-units --type=target
as a replacement. The problem? That command is not replacement, and does nothing at all to tell you what the runlevel is, just what things of type target are enabled.

In a sense I think these types of blatant documentation bugs are caused by a sort of inner embarrassment that something super trivial simply isn't being done, for no good reason.
Back to top

libc6-i386 re that, annoyingly, I have no system to test this on at the moment, I've found that only fairly rigorous testing can actually pinpoint what is needed when assembling package groups.

However, I suspect there is at least one other package required, some glx thing, since that was the actual problem I believe. But I do not know, sadly. Nor does as of yet anyone else seem to know.

Eventually, if we can collect the actual data, I will be able to assemble a package group that will actually do what the metapackage did, but it will take a lot of wasted time, none of which should have been necessary, which is the very worst kind of free software event in my opinion, bad decisions wasting other devs time when that was not necessary or desirable and no good reason can actually be given for the bad decision. But we have to live with this stuff, it's the cost of free software, as one notes when reading the gpl, it notes always, the often forgotten qualifier, that no warranty is provided or suggested, and no guarantee of fitness for the task is given. I just wish maintainers and developers would not take advantage of that qualifier, and learn to think a little bit more when making certain decisions, it's not a huge amount to ask, and the long term benefits are huge in terms of making free software more widely usable and accessible.
Back to top

At least I didn't install any glx i386 packages explicitly. May be wine32 and common wine libs pulled it in, however somehow they didn't pull in libc, and because of that the whole dynamic binding went wild. I can try purging wine and check again what's being installed.
Back to top

Here what I got trying to remove wine packages which I installed previously (it also wipes playonlinux which depends on wine):



So you were right, some glx packages were probably also needed, but they were pulled as dependencies, so I didn't need to install them manually. libc binding however was left out, and that caused me all the problems above. So now we know, it should be installed manually. Other good package which is useful for Wine but isn't pulled with it is libasound2-plugins:i386.

I think installing playonlinux + libasound2-plugins:i386 + libc6-i386 can simplify all that (note, that's libc6-i386, not libc6:i386 there).
Back to top

these look like likely contenders for what the nvidia driver 64 bit stuff actually needs:



but i have no 64 bit test system to actually debug the issue for the nvidia driver.

I believe the issues with the nvidia driver would be the same as for wine, or at least very similar, re what i386 libs are needed.
Back to top