[Pkg-ia32-libs-maintainers] ia32-libs-dev transitional package?

[The Wanderer]

On 01/09/2013 02:59 AM, Goswin von Brederlow wrote:

> On Tue, Jan 08, 2013 at 09:38:50AM -0500, The Wanderer wrote:
> 
>> On 01/08/2013 04:30 AM, Goswin von Brederlow wrote:

>>> Seems more like the wine package should be split into wine and
>>> wineserver. The former would be M-A: same and the later would be M-A:
>>> foreign.
>> 
>> While possibly true, that doesn't help with people who are wanting to build
>> wine themselves, e.g. to track git (and possibly even contribute to
>> development). At best, it means they have to deal with two
>> previously-unnecessary intermediary elements of the build process: the
>> 32-bit chroot and the building - and then, later, installing - of Debian
>> packages.
> 
> They would have to build a pure 32bit wine, a pure 64bit wine or both
> depending on what they want to test.

But the combined functionality of a combined build is different - if only in
that it allows 32-bit programs to successfully launch 64-bit ones and vice
versa, which can be essential for e.g. chained install processes. (Or probably
for something as simple as launching a 32-bit program from within a 64-bit file
manager.) With separately built versions, at least according to the Wiki's 
latest information that I know of, that doesn't work.

Not to mention that this isn't necessarily just for test usage, but can be for
actual production usage, which is what I've been using such builds for.

I'm quite confident that Debian package maintainers will find ways to make
whatever they need to get packaging done work, however clunky (e.g. a cross-arch
chroot) or kludgy (e.g. manually swap installed -dev packages in between build
stages, as I've already seen suggested) those ways may be. What I'm concerned
about is how to let these things keep working for ordinary users, who aren't
building Debian packages and don't want to deal with any such elaborate
workarounds.

>>> I'm assuming the --with-wine64 only excludes some stuff from being build
>>> and doesn't alter the stuff that actualy does get build. But that is just
>>> a guess.
>> 
>> I've just looked over the source (or at least the build system), and I
>> don't see any way in which it alters anything which actually does get
>> built, although there are a few more things than just wineserver which are
>> used from the 64-bit side in the -with-wine64 case (tools, fonts, and
>> apparently man pages being the only ones I've noticed so far).
>> 
>> There may still be a problem, however, due to the use of that tools/
>> directory. Those tools appear to be used during the actual build process,
>> and the --with-wine64 build simply reuses the ones built during the
>> -enable-win64 build; naturally enough, those tools are 64-bit, and
>> dynamically linked.
>> 
>> If those tools are needed during the build process, which they appear to
>> be, then the --with-wine64 build likely won't work properly in a strictly
>> 32-bit environment. An i386 chroot may not be a "strictly" 32-bit
>> environment (in that it's still hosted on a CPU and under a kernel which
>> can handle amd64 code), but since the tools are dynamically linked, they
>> may fail anyway.
> 
> You wouldn't use --with-wine64 at all. You build a pure 32bit wine on i386, a
> pure 64bit wine on amd64 and then install the packages you want.

I seriously doubt the result would work the same way as a combined build. If it
would, why does the Wine wiki recommend that elaborate multi-build-tree approach
to getting what it calls a "shared" setup working, instead of just recommending
that you compile and install the 32-bit and 64-bit Wine in that order?

> I'm assuming the 32bit wineserver (and other tools) would work just as well
> as the 64bit ones for a 32/64 wine, too. Otherwise the depends would get a
> bit more complex to ensure you always get a 64bit wineserver under multiarch.

I don't expect it would work just as well, no. It might be fine for the 32-bit
side, but I would expect the 64-bit side to end up having problems.

Using a 64-bit wineserver and tools for both sides would be more likely to work,
but I'm still not sure it would produce the same behavior as a "shared" build.

There's documentation on the Wine wiki (linked from the page I linked to) about
exactly which 32-bit Wine files you need to package for a Wine64 install to be
functional, but although the phrasing on the wiki is ambiguous, I think what
it's talking about is a non-"shared" install. A combined-build install might
well need more.

>> Two other things.
>> 
>> One, from the fact that you didn't reply to my question about it I infer
>> that there is in fact nothing in particular I could do to help out with the
>> multi-arch -dev transition.
> 
> Not for this release anyway. After that the sky is the limit.

Well, obviously not for the wheezy release; by the nature and status of the
freeze, it's quite plain that this transition isn't going to happen for that
release.

I was thinking more about what might need help after that (since, at a glance,
it looks like most of it would be the sorts of things which only the individual
package maintainers could handle), and of the "backend" problems you referenced
by saying that "not all cross-compile issues under multiarch have been resolved
and put into specs yet", and so forth.

(Also, I'd still be interested in the question of the intended ETA for this -
jessie? jessie+1? something else?)

>> Two, is there a reason why I am receiving your replies only directly to
>> myself, rather than (either also or exclusively) through the list? I'd
>> prefer to receive them through the list, and I have "suppress duplicates"
>> turned off everywhere I can find on my mail provider's side, but I don't
>> seem to be receiving the allegedly duplicate copies which should have come
>> through the list. (Although I do receive copies of my own messages.)
> 
> Hmm, I might have hit the wrong key and not done a list reply. Sorry, new
> email client I'm testing.

No, your replies do include the list in Cc:, as well as me in To:. It's just
that the copy via the list never reaches me.

The last time I saw something like this happen, I contacted my mail provider to
ask whether the "allow duplicates" config setting wasn't working, and they
suggested I contact the list maintainers and ask whether the mailing list itself
was configured to suppress duplicate messages. I seriously doubt that this one
would be, but it's the only other thing I can think of, and if we can confirm
that it isn't then I can take the question back to my mail provider.

Who would the "list maintainers" be in this case? The only indication I see is
the "list owner" link from the subscription page, which doesn't sound like quite
the same thing.

-- 
    The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Every time you let somebody set a limit they start moving it.
   - LiveJournal user antonia_tiger