Re: 64-bit time_t transition for 32-bit archs: a proposal
On Wed, 07 Jun 2023 at 07:19:39 -0000, Sune Vuorela wrote:
> On 2023-06-07, Paul Wise <pabs@debian.org> wrote:
> > I note that there are a number of packages available on i386 but not
> > available on amd64, is anyone planning on an MBF about this issue?
>
> game stuff, mostly contrib, likely binary data for binary blobs
> > steam deb contrib/oldlibs optional arch=i386
> > steam-libs-i386 deb metapackages optional arch=i386
> > steamcmd deb non-free/games optional arch=i386
Steam consists of proprietary binaries which are a mixture of i386 and
amd64. It functionally requires *both* architectures to work. The top-level
package for how this now works in Debian is steam-installer.
The 'steam' package is a transitional package from an older packaging
scheme where it was possible to run on purely 32-bit systems (that is
not true any more), so it is only useful when upgrading existing
32-bit-capable machines.
Even if Valve chose to port the main Steam client executable to amd64,
the purpose of Steam is to run Steam games, and a lot of the older
games (like Team Fortress 2) are proprietary i386 binaries. As long as
that's the case, which in practice it will be forever, we'll need the
steam-libs-i386 metapackage to pull in at least the subset of those games'
dependencies that they cannot usefully bundle (mainly glibc and Mesa).
steamcmd is a proprietary i386 binary. No amd64 version exists, so
until/unless Valve produce one (likely to be a vanishingly low priority),
the only options are i386 or remove.
> > etqw deb contrib/games optional arch=i386
> > etqw-server deb contrib/games optional arch=i386
> > quake4 deb contrib/games optional arch=i386
> > quake4-server deb contrib/games optional arch=i386
These are wrappers around proprietary i386 binaries which are not in
Debian for licensing reasons, but can be packaged locally by using
game-data-packager. No amd64 version exists, and only their developer
(indirectly Microsoft, which owns ZeniMax, which owns id Software)
could produce one, which in practice is unlikely to happen; so the only
options are i386 or remove.
smcv
Reply to: