Re: ia32-libs transition
On Tue, Jun 30, 2009 at 05:11, Goswin von Brederlow<goswin-v-b@web.de> wrote:
> Aneurin Price <aneurin.price@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
Reply to: