Page: Previous  1, 2

shmerl
Status: Interested
Joined: 18 Apr 2012
Posts: 30
Reply Quote
I was able to narrow it down to one critical package: libc6-i386...
Back to top
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4075
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
:: Quote ::
This is indeed weird, I never had such experience with Debian before. I can understand the logic behind dropping that metapackage though - it was a tradeoff. Everything in one pile to cover many needs. But it was cluttering. So Debian decided to remove it insisting on something like "install stuff individually, we now have multiarch". The problem is, users have no easy way to figure out what to install! (Like in this very case). To help that, some metapacakges need to be created to address such cases. Something like wine-i386-support or something.


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
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4075
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
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
shmerl
Status: Interested
Joined: 18 Apr 2012
Posts: 30
Reply Quote
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
shmerl
Status: Interested
Joined: 18 Apr 2012
Posts: 30
Reply Quote
Here what I got trying to remove wine packages which I installed previously (it also wipes playonlinux which depends on wine):

:: Code ::
sudo apt-get purge wine64 wine32 wine libwine-gecko-1.4 libwine:amd64 libwine:i386
Reading package lists... Done                                                                                                                                         
Building dependency tree                                                                                                                                             
Reading state information... Done                                                                                                                                     
The following packages were automatically installed and are no longer required:
  libdb5.1:i386 libdrm-intel1:i386 libdrm-nouveau2:i386 libdrm-radeon1:i386 libdrm2:i386 libelf1:i386 libexif12:i386 libexpat1:i386 libffi6:i386 libfontconfig1:i386
  libfreetype6:i386 libgcrypt11:i386 libgd3:i386 libgl1-mesa-dri:i386 libgl1-mesa-glx:i386 libglapi-mesa:i386 libglu1-mesa:i386 libgnutls26:i386 libgpg-error0:i386
  libgphoto2-2:i386 libgphoto2-port0:i386 libjbig0:i386 libjpeg8:i386 liblcms2-2:i386 libldap-2.4-2:i386 libllvm3.3:i386 libltdl7:i386 libmpg123-0:i386
  libopenal-data libopenal1 libopenal1:i386 libp11-kit0:i386 libpciaccess0:i386 libpng12-0:i386 libsasl2-2:i386 libsasl2-modules:i386 libsasl2-modules-db:i386
  libssl1.0.0:i386 libtasn1-3:i386 libtiff5:i386 libudev1:i386 libusb-1.0-0:i386 libxcb-dri2-0:i386 libxcb-glx0:i386 libxcursor1:i386 libxdamage1:i386
  libxfixes3:i386 libxml2:i386 libxpm4:i386 libxrender1:i386 libxxf86vm1:i386 python-wxgtk2.8 python-wxversion ttf-liberation
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
  libwine* libwine:i386* libwine-gecko-1.4* playonlinux* wine* wine32:i386* wine64*
0 upgraded, 0 newly installed, 7 to remove and 0 not upgraded.


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
techAdmin
Status: Site Admin
Joined: 26 Sep 2003
Posts: 4075
Location: East Coast, West Coast? I know it's one of them.
Reply Quote
these look like likely contenders for what the nvidia driver 64 bit stuff actually needs:

:: Code ::
libdrm2:i386  libgl1-mesa-dri:i386 libgl1-mesa-glx:i386 libglapi-mesa:i386 libglu1-mesa:i386 libxcb-dri2-0:i386 libxcb-glx0:i386 libxcursor1:i386 libxdamage1:i386   libxrender1:i386


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
Display posts from previous:   
Page: Previous  1, 2
All times are GMT - 8 Hours