RFC: x86-runtime packages (was: Re: libexec and multi-arch)

[Tomasz Pala]

On Mon, Feb 12, 2018 at 09:04:07 +0100, Jacek Konieczny wrote:

> I was thinking about some other solution: Make some '32bit runtime'
> packages which would be built from our i686 packages and contain only
> the libraries and other necessary files needed to run x86 apps on x86_64
> system.
[...]
> Updating of the spec files could be partially automated.

If doing any magic on spec files, one could as well make them pure libs
(no other contents, except maybe for %_docdir) and the problem is solved.
However, this is not what should be done manually these days - I would
expect the package manager to either - build such pure libs subpackage
automatically (at most marking the spec files with some macro) or ignore
the conflicting contents during the install.

> This packages would be explicitly made not to conflict with anything
> from x86_64 packages and installing .i686 packages in x86_64 system
> would not be needed any more.

This is only part of the problem - there are other cases:
- installing multiple versions of some library in single arch (for legacy
  software),
- installing 32-bit apps in 64-bit environment - this MIGHT require
  installing other than pure-libs packages from 32-bit tree,
- installing packages from other distros, a PLD lacks MANY of useful
  software these days, or has some very old versions. I am really tired
  of compiling everything I want to use from sources, especially when
  time is a matter.

I am also tired of manually creating libs/devel/static subpackages (with 
dumb "%{name} devel files" descriptions and %post ldconfig repating all
over again) in spec files - this is SO automatable... Such development
is doomed.

> The packages could be:
> 
> x86-runtime-basesystem (glibc, libstdc++ with dependencies)
> x86-runtime-X11 (X11 libraries, maybe with the popular toolkits)
> x86-runtime-SDL (SDL_* ??? mostly for games)
> etc.

LDAP, kerberos, SASL, all-the-databases...? In fact, most of the
32-bit libs might be required.

This is much work for something, that should be handled by single tool.
What we need is some SysV->systemd-like transition for rpm, which is not
doing it's job. It was fine in '90s, but the world has changed.
Especially when there is appropriate code in core of rpm (colouring),
but the trivial solution is rejected by stucked in his own flat world
maintainer. Relying on such software has no future without tons of
package-maintainers.

-- 
Tomasz Pala <gotar at pld-linux.org>