Re: ia32-libs transition

[Goswin von Brederlow <goswin-v-b@web.de>]

Aneurin Price <aneurin.price@gmail.com> writes:

> 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

That would require you to hit ctrl-C in the preinst between a mv and a
ln command. Or on remove between dpkg removing the package and running
postrm where the diversion is undone. In both cases you would have a
half-installed package due to your ctrl-c-ing.

> after setting Cache-Limit to 50331648 - but why did it only start doing that
> after a couple of goes? Couldn't say.

That makes 4 people having hit that libapt bug.

> 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.

I verry rarely have enough random bits for gpg to create a key. Even
after hours of uptime without using gpg. Other things eat up enough to
keep the pool small. But I never had it block for hours waiting for
more. Usualy continious quickly. Do you use ssl for mail and had a
fair amount of mail traffic? I heart that that eats up random bits
like crazy.

> 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.

You only need "apt-get update". The rest works in aptitude or synaptic.

>>> 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.

With version 19 (on mentors.debian.net) you can now also do

aptitude install ia32-apt-get
aptitude update
aptitude install ia32-wine

You only need one round of update after ia32-apt-get. ia32-wine
depends on all the libraries it needs and pulls them it. It doesn't
need an upgrade of ia32-libs before it is installable.

> 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

apt-file needs to be patched for multiarch so it can cope with
multiple Contents-$ARCH files eventually. If you do that now it will
function more and more as libraries are converted to multiarch even if
ia32-apt-get is still used to install them. Remember that packages can
convert to multiarch prior to dpkg/apt/aptitute/synaptic/... being
multiarch capable.

> * Doesn't care about packages not being shown 'correctly' in eg.
> aptitude/apt-cache search, at least until the magic setup process is complete.

"correctly"? Inbetween installing ia32-apt-get and running update for
the first time after that there is small window where some index files
will be unavailable. I'm not aware though that that affects how
packages are shown in aptitude or apt-cache. I use apt-cache quite a
lot and it displays things just fine for me.

> * 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)

Temporary.

> 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

Actualy the "being transparent" part is what 99% of you are screaming
about. Or the bumps in the road towards it. So far you have seen one
single version and the first one to attempt this transparency. Please
do give it a change to mature before condeming it.

MfG
        Goswin