On Tue, Jun 30, 2009 at 05:11, Goswin von Brederlow<goswin-...@web.de> wrote: > Aneurin Price <aneurin.pr...@gmail.com> writes: > >> Hi, >> >> I've just spent over an hour writing and rewriting this mail, and determined >> that I can't think of a single constructive thing to say.
Not wanting to leave it at that, I've spent a couple of hours today trying to pin down some specifics. Unfortunately I've not had much success. Purging everything related to 32bit compatibility and reinstalling doesn't ever seem to have exactly the same effect - so far I've seen numerous problems, but none of them reproducibly, and many of them making no sense at all - eg how in the world did I lose /usr/bin/dpkg-deb at one point? No clue. The apt segfault went away after setting Cache-Limit to 50331648 - but why did it only start doing that after a couple of goes? Couldn't say. I suspect that all of my problems are secondary damage rooted in a problem I had the first time I tried the update: installing ia32-apt-get requires a ton of entropy to generate a private key (why? beats me). Unfortunately, my system didn't seem to be able to generate sufficient randomness even after an evening of use, so eventually I ^Cd it just so that at least the dpkg database lock would be released. I'm aware that this isn't a good idea, but I didn't feel that I had a great deal of choice - plus I've never had a partial package install be such a headache to clean up before. Curiously, in my later repeats of the process it never took more than a couple of minutes to generate enough entropy, and usually it was less than a minute, so I'm not sure why it had such a problem the first time. Or maybe that, once cleaned up, wasn't the end of the world after all. Another possibility is that I didn't realise until I'd read the other thread that you need to use apt-get to complete the process, so I just used aptitude the first couple of goes, as I usually do. >> >> So I'll just ask a couple of questions instead: >> >> Is there any way of preventing this kind of major breakage in the future? >> I don't think many people expect that upgrading one package will FUBAR >> the packaging system. >> >> Is there any chance of Wine becoming functional on amd64 in the forseeable >> future? > > # apt-get install ia32-wine Except that it's really: apt-get update apt-get upgrade apt-get update apt-get install ia32-wine Rather than: aptitude update aptitude install wine At least that's what I assume. I can't get past the second apt-get update without something breaking. > Reading package lists... Done > Building dependency tree > Reading state information... Done > The following extra packages will be installed: > ia32-libwine ia32-libwine-alsa ia32-libwine-cms ia32-libwine-gl > ia32-libwine-gphoto2 ia32-libwine-ldap ia32-libwine-print ia32-libwine-sane > ia32-wine-bin ia32-wine-utils > Suggested packages: > wine-doc binfmt-support ttf-mscorefonts-installer winbind avscan klamav > clamav > Recommended packages: > ttf-liberation > The following NEW packages will be installed: > ia32-libwine ia32-libwine-alsa ia32-libwine-cms ia32-libwine-gl > ia32-libwine-gphoto2 ia32-libwine-ldap ia32-libwine-print ia32-libwine-sane > ia32-wine ia32-wine-bin ia32-wine-utils > 0 upgraded, 11 newly installed, 0 to remove and 187 not upgraded. > Need to get 11.0MB of archives. > After this operation, 51.4MB of additional disk space will be used. > Do you want to continue [Y/n]? y > ... > > % winemine > > Have fun. Works both with sid and experimental wine. Provided you have > a lib32ncurses5 and lib32readline5 with the lib32 transition completed > that is. Bug the respective maintainers for that one. > >> Did anyone who isn't on crack get to see 'ia32-apt-get.preinst' and >> 'ia32-apt-get.postinst' before they were perpetrated upon an unsuspecting >> populace? Reading them in the process of trying to unfuck my system made me >> feel more than slightly ill. > > Since my package was sponsored I would assume at least one other > person looked over it. You are the first to mention illness. I can't > change what it does. But do you have suggestion to improve how it does > things in preinst/postinst/postrm? > To be honest, I say we take off and nuke the entire site from orbit. You can't just hack together a quick shell script for something that major. It's far too brittle. > Latest source is on svn.debian.org pkg-ia32-libs: > http://svn.debian.org/wsvn/pkg-ia32-libs/trunk/ia32-libs-tools/#_trunk_ia32-libs-tools_ > This entire direction is a dead end. Having these extra package databases and dpkg-diversions only works in a very narrow set of circumstances. It's only a workable solution if you assume that everyone: * Uses apt-get and nothing else * Doesn't care about having other package-related tools like apt-file fully functional * Doesn't care about packages not being shown 'correctly' in eg. aptitude/apt-cache search, at least until the magic setup process is complete. * Reads the documentation and knows that they have to complete a multi-step process. * Is actually happy to do so * Is always going to know specifically that a certain package they want must be prefixed with ia32- (it's no longer possible to say 'install wine'; now the user needs to know what arch they're using) All this time and effort seems to have gone into producing a system which has almost no real benefits over the existing kludge, but has a ton of drawbacks and is, from a usability point of view, a disaster. Unless the transition process can be made *entirely* transparent to the end user, then any change from the old ia32-libs way is worse, regardless of its technical features. I believe this reason alone should be sufficient to revert to the previous kludgy system. -Nye -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
