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 <go...@pld-linux.org> _______________________________________________ pld-devel-en mailing list pld-devel-en@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-en